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Section  1 
INTRODUCTION 


This  report  documents  "The  Navy  Computer  Accreditation  Study"  performed 
by  the  IBM  Federal  Systems  Division  for  the  Assistant  Secretary  of  the 
Navy,  Office  of  Naval  Research,  under  Contract  N00014-79-C-0986.  IBM 
would  like  to  thank  Mr.  W.R.  Smith  (Scientific  Officer,  Assistant  Secretary 
of  the  Navy,  Office  of  Naval  Research),  Messrs. D.  Barry  and  P.  Mankofsky 
(Naval  Underwater  Systems  Command,  NUSC/3551),  and  the  two  Navy  re¬ 
view  teams,  whose  comments  and  support  data  provided  guidance  for  this 
study. 

This  study  was  initiated  by  the  U.S.  Navy  in  recognition  that  an  exam¬ 
ination  should  be  performed  of  shipboard  computer  acquisition  policies  to 
meet  future  Navy  needs  and  priorities  as  well  as  reflect  the  anticipated 
"environment"  (technology,  LCC,  business  costs,  etc.)  It  should  be  noted 
that  just  the  estimated  initial  acquisition  costs  for  shipboard  computers 
will  be  almost  $1  billion  over  the  next  10  years,  thus  emphasizing  the 
importance  of  future  effective  acquisition  policies. 

The  primary  objectives  of  this  study  was  for  IBM  to: 

•  Examine  accreditation  concept  candidates 

•  Define  a  meaningful  policy  and  management  framework  for  future  Navy 
needs 

•  Provide,  where  possible,  specific  details  to  put  into  the  policy/ 
management  structure 

•  Support  the  proposed  accreditation  approach  with  rationale  and  analysis. 

With  these  "objectives"  in  mind,  IBM  proceeded  to  develop  a  study  meth¬ 
odology  which  could  best  examine  the  concept  of  accreditation. 


1.  1  THE  ACCREDITATION  CONCEPT 

IBM's  early  analysis  indicated  that  many  variations  of  the  accreditation 
concept  existed,  that  these  concepts  were  sensitive  to  priorities  at  hand 
(e.  g. ,  operational  readiness,  recruitment  problems,  cost,  etc.),  and, 
finally,  that  it  was  not  reasonable  to  expect  a  precise  definition  of  accredi¬ 
tation  as  it  is  still  evolving  and  the  study  would  further  that  end. 

As  a  departure  point  for  the  study,  it  was  established  that  accredi¬ 
tation  is 

"A  set  of  future  Shipboard  computer  acquisition  policies  and 
practices  that  will  allow  the  U.  S.  Navy  to 

•  Most  effectively  utilize  advancing  technologies 

•  Be  responsive  to  operational  readiness  needs  and  weapon  system 
requirements 

•  Be  sensitive  to  ever  increasing  cost  of  ownership  and  manpower 
availability 
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•  Provide  adequate  opportunities  for  industry  competition  with  attractive 
market  definition. " 

In  other  words,  one  can  view  accreditation  as  the  next  evolution  of  Navy 
acquisition  policies  deemed  most  effective  and  acceptable. 


1.  2  THE  ACCREDITATION/STANDARDIZATION  RELATIONSHIP 


The  benefits  of  standardization  are  well-known.  Standardization  of  com¬ 
puters  enables  the  DoD  to  effectively  manage  the  proliferation  of  numerous 
computer  hardware  architectures/types,  thereby  providing 

•  Management  of  software  proliferation,  which  is  a  significant 
cost  contribution  in  the  development  and  maintenance  of  systems 

•  Utilization  of  common  support  software  tools  and  minimization  of 
retraining  of  programmers 

•  Common  logistics  support  (critical  in  shipboard  applications),  enabling 
lower  O&M  costs,  maintenance  training  requirements,  common  test 
equipment,  and  a  manageable  spares  situation 

•  Minimization  of  risk  to  the  weapon  system  developer  because  of  known, 
tested,  and  supported  hardware 

•  Opportunity  to  procure  on  a  large  commodity  basis,  providing 
production  cost  leverage. 

However,  there  can  be  come  significant  disadvantages  to  "rigid 
standardization",  such  as 

•  Inability  to  take  advantage  of  advanced  technology,  which  precludes 
the  benefits  of  lower  cost  and  more  reliable  and  testable  hardware 

•  Lack  of  competition,  which  can  inhibit  potential  innovations  and  system 
alternatives  that  would  provide  the  DoD  with  either  a  better  product  or 
lower  production  cost. 

There  are  also  "degrees  of  standardization",  which  range  from  iden¬ 
tical  hardware  from  a  single  source  for  an  extended  period;  to  standard¬ 
ized  ISAs  with  hardware  procured  to  the  ISA  on  a  form,  fit,  and  function 
basis;  to  numerous  "approved"  "off-the-shelf  computer  standards",  from 
which  Navy  Program  managers  pick  and  choose.  Examples  of  standard¬ 
ization  programs  currently  in  DoD  are  summarized  and  compared  in  Table 
1-1.  Note  that  each  standardization  program  is  geared  to  each  service's 
priorities  and  weapon  development  situation.  This  is  a  reasonable 
approach  to  standardization. 

There  is  also  another  dimension  to  standardization:  that  of  a  higher- 
order  language  (HOL)  standard.  Given  that  all  operational/applications 
software  were  written  at  the  HOL  level,  and  it  was  a  matter  of  compiling 
toward  a  target  machine,  that  might  be  a  factor  in  determining  the  rigidity 
of  the  "computer  hardware  standards  policy.  "  IBM's  study  of  accredita¬ 
tion,  however,  did  not  address  this,  on  the  basis  of  an  initial  study  ground- 
rule  exempting  software  considerations. 
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Table  1-1.  Current  DoD-Service  Standardization  Approaches 


Specified 

Standard 

Principal 

Objective 

Comments 

Reduced 

Software 

Development 

Cost 

Lower  Hardware 
Acquisition 

Costs  via 
Competition 

Lower 

Hardware 

Logistics 

Cost 

Ease  of 

Technology 

Insertion 

Investment 

Incentive 

Air  Force 

1750  ISA  & 

J-73  HOL 

Software  cost; 
technology 
insertion, 
hardware  costs 

Box-dependent 
speed,  timing. 

(F^)  procured  by 
platform 

(Multiple 

suppliers) 

++ 

Standard  ISA 

+ 

Only  by 
platform 

+ 

(No 

serious 

constraints) 

+ 

(Frequent 
recompetition 
possible.  Large 
potential  volume) 

Navy  UYK-7/20 
hardware  & 

CMS- 2  HOL 

LCC  reliability  & 
maintainability, 
Software  cost 

reduction 

Rarely  second 
sourced.  Minimal 
technology 
evolution. 

(Standard  ISA  by 
history) 

•H- 

Standard  ISA 

(+W/dual 

source) 

+ 

(Fewer 

module 

types) 

(Sunk 

cost 

slows 

technology 

insertion) 

+ 

(Limited 
recompetition. 
Large  volumes. ) 

Army-MCF 
Nebula  ISA  & 
ADA  HOL 

ADP  surviva¬ 
bility,  LCC 
maintainability 
reliability 

Box  F3,  winner 
take  all  produc¬ 
tion,  standard 

ISA 

++ 

Standard  ISA 

+ 

+ 

(No 

serious 

constraints) 

+ 

(Multiple 
developments, 
large  production 
commitment) 

Accreditation,  as  determined  b;y  this  study,  is  a  concept  which  em¬ 
bodies  the  benefits  of  standardization,  addresses  some  of  the  potential 
disadvantages  of  too  repressive  a  standardization  concept,  and  provides 
a  policy  framework  which  permits  more  flexibility  through 

•  More  frequent  but  timely  redevelopment 

•  Standardization  of  ISA s,  but  hardware  development  at  the  F  level 

•  Goverment-funded  development  that  will  enable  "competition"  without 
undue  financial  risk  to  industry  as  well  as  undue  sensitivity  to  market 
projection  inaccuracies 

•  Consolidated  procurement  to  more  effectively  take  advantage  of  quantity 
leverage,  provide  a  focal  point  for  computer  procurement  policy  as  a 
function  of  an  evolving  environment,  and  provide  centralization  of  govern¬ 
ment  cost 

•  Periodic  concept  formulation  studies  to  revalidate  or  revise  the  accred¬ 
itation  framework. 


1.3  STUDY  REPORT  CONTENTS 

To  provide  a  further  characterization  of  the  accreditation  concept,  Section 
2  discusses  acquisition  scenario  considerations  and  key  issues  that  must 
be  considered  in  the  formulation  of  an  accreditation  concept.  The  study 
methodology  is  organized  to  address  these  key  factors. 
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Section  3  examines  technology  trends  and  defines  cost/performance 
and  reliability  rates  of  improvements.  These  rates  of  improvement  are 
then  used  as  data  for  input  to  the  Life  Cycle  Cost  analysis  of  Section  4. 

The  market  size,  defined  in  Section  4,  coupled  with  the  spares  data  result¬ 
ing  from  the  Life  Cycle  Cost  model,  are  used  by  the  profitability  analysis 
in  Section  5. 

Section  6  discusses  computer  acquisition  strategies.  Section  7  is  a 
collection  of  additional  issues,  and  discusses  the  level  of  standardization 
(build-to-print  vs.  form,  fit,  and  function) ,  the  architecture  certification 
process,  and  the  relevance  of  commercial  developments.  Finally,  Section 
8  summarizes  the  results,  and  Section  9  summarizes  the  future  recom¬ 
mendations  of  the  Accreditation  Study. 
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Section  2 

CURRENT  NAVY  POLICIES 


The  Navy  was  the  first  service  to  exploit  the  aspect  of  computer  standard¬ 
ization  out  of  the  practical  aspect  of  common  hardware  and  software  on 
multiple  ship  platforms.  The  Navy's  Acquisition  policies  for  shipboard 
computers  is  an  evolving  one,  as  characterized  and  analyzed  in  Figure 
2-1.  Whereas  the  CP-642,  AN/UYK-7,  AN/UYK-20,  and  AN/AYK- 
14  computers  were  single-source  development  and  production  items 
with  the  described  disadvantages  and  advantages  of  such  an  ap¬ 
proach,  the  upcoming  NECS  procurement  is  characterized  by  dual 
development  and  anticipated  leader/follower  production  competition. 

A  potential  step  beyond  this  in  future  procurements  might  be  the 
accreditation  concept,  characterized  by  multiple  developments,  optimized 
production  sources,  and  then  another  redevelopment  placing  emphasis  on 
F^  to  allow  for  integration  of  advanced  technology.  There  are  many  vari¬ 
ations  of  this  postulated  concept  of  accreditation  that  also  solicit  questions 
and  identify  factors  to  be  considered;  these  are  discussed  in  the  following 
subsections. 

o  CP-642  UYK-7/UYK-20/AYK-14  Advantages  Disadvantages 

Multiple 


R&D  V 

Development 

\ 

Production 

Minimum  government 

Limited  control 

proposals  / 

contractor 

/ 

contractor 

1 

1 

| _ Potential 

second  source 

development  cost 
o  Procurement 
o  Supplier 

Interface 
Minimum 
logistics  support 

production  costs 
o  Single  supplier 
o  Technical 
immobility 

NECS  (UYK-43) 

Multiple 

R&D  \  Dual  development 

Development 

alternatives 

Parallel 

Development 

affordability 

Technology 

proposals  / 

contractors 

Production 

proposals 

Production 

contractor 

\  Leader 

competition 

throughout 

development 

insertion  versus 
redevelopment 

Follower  NRSU 

Production 
reprocurement  to 
preferred  source 
only 

\follower 

Minimum 

logistics 

cost 

Accreditation 

Multiple 

R&D  V 

Multidevelopment 

Accredited 
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Figure  2-1.  Evolution  of  Acquisition  Strategies 
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2.  1  ACCREDITATION  SCENARIO  CONSIDERATIONS 


To  effectively  establish  a  framework  for  accreditation,  it  was  necessary 
to  postulate  the  key  elements/participants  in  such  a  concept  and  then 
analyze  the  interrelationships  between  these  key  elements  to  determine 
what  issues  in  accreditation  the  study  should  focus  on  and  integrate  into 
its  methodology. 

The  key  concept  elements/participants  were  considered  first  as  de¬ 
picted  in  Figure  2-2: 

•  Weapon  systems  developer(s) 

•  Platform  managers 

•  Computer  development  manager(s) 

•  Procurement  manager 

•  Certification  facility 

•  Industry  computer  sources. 

Consider  the  potential  relationships  between  each  of  these  key  elements 
which  begin  to  formulate  the  framework  for  accreditation  and  which  lead 
to  these  "factors"  which  must  be  defined  to  solidify  this  framework.  One 
can  begin  by  asking  some  questions  in  terms  of  what  role  these  key  players 
have  in  the  accreditation  process: 

•  How  are  the  industry  computer  sources  selected? 

—  Competition? 

—  Off-the-shelf  products  ? 

—  Other? 

•  What  is  the  role  of  the  Weapon  System  developer? 

—  Computer  developer? 

—  Requirements  generation? 

—  Integration  ? 

—  Funding  source? 

•  How  are  platform  managers  involved? 

—  Integration  ? 

—  Logistics  commonality  ? 

—  Weapon  system  validator? 

•  How  are  computers  developed  and  by  whom  ? 

—  Government  funded? 

—  Certification  process  ? 

—  Industry  products  ? 

•  Should  computers  be  procured  via  a  "centralized"  commodity  manager 
concept? 

Given  the  roles  of  the  key  players,  we  must  evaluate  the  Accredita¬ 
tion  Scenario  Alternatives  to  identify  key  factors  that  can  be  integrated 
into  the  accreditation  framework.  In  other  words,  the  identification  of 
key  factors  which  will  structure  the  study  methodology  must  be  derived 
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Figure  2-2.  Accreditation  Participants 

by  examining  candidate  accreditation  scenarios.  The  following  are 
examples  of  what  were  potential  considerations: 

•  Scenario  considerations  -  Proposition  A 

—  The  Navy  lets  multiple  development  contracts  through  a  develop¬ 
ment  manager/office. 

—  X  developers  qualify  for  EDM  phase  to  compete  for  production. 

—  Other  developers  may,  on  their  own,  submit  their  computers  for 
Navy  evaluation. 

—  All  developers  certify  their  hardware  to  an  ISA  standard  and 
MIL-SPEC  requirements. 

—  A  procurement  manager  compiles  all  weapon  system  managers' 
computer  requirements. 

—  The  platform  manager  inputs  the  logistics  considerations  to 
the  procurement  manager. 

—  A  single  producer  is  chosen  for  production,  with  potential 
second  source  options. 

—  This  now  becomes  the  standard  until  the  next  development 
cycle. 
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•  Scenario  considerations  -  Proposition  B 

—  A  Navy  development  office  releases  a  "general"  set  of  require¬ 
ments,  intended  applications,  projected  market  size. 

—  A  certification  process  is  established  to  ensure  that  the  "general 
requirements"  are  met. 

—  Industry  computer  sources  review  requirements  and  submit  their 
candidates  for  certification. 

—  producers  are  certified  by  the  Navy,  and  a  "list"  is  formulated 
for  the  procurement  manager. 

—  The  list  is  frozen  for  X  years  and  then  reopened  for  new  candi¬ 
dates;  no  "exception  process"  is  provided. 

—  Weapon  system  and  platform  managers  review  the  "list",  select  a 
producer's  computer  that  best  fills  their  needs,  then  fund  and  pro¬ 
cure  the  computers  themselves. 

—  Where  possible  and  on  a  timely  basis,  the  procurement  manager 
would  try  to  consolidate  computer  buys  for  PMSs  and  PARMs. 

—  After  X  years,  the  total  process  is  repeated. 

The  eventual  solidification  of  an  accreditation  process  and  policy  will 
probably  consist  of  elements  described  in  examples  of  both  scenario 
propositions,  and  other  considerations.  The  examples  were  not  meant  to 
be  all  encompassing,  but  rather  they  were  derived  to  elicit  factors  that 
should  be  studied  for  the  concept  of  accreditation.  The  following  sections 
discuss  those  factors  identified  by  IBM  that  would  best  help  in  the  analysis 
and  definitization  of  accreditation. 


2.2  ACCREDITATION  STUDY  FACTORS 

The  study  factors  identified  were  divided  into  three  major  categories: 

•  roles  of  accreditation  players 

•  certification  considerations 

•  acquisition  process. 

They  were  then  integrated  as  outputs  of  the  suty  to  be  performed. 

The  study  factors  are  as  follows: 

•  Certification  process 

—  What  specifications  will  be  established  for  industry? 

•  ISA  functions  only 

•  Performance  specs/operational  needs 

•  Environmental  considerations. 

—  What  are  the  general  characteristics  of  the  computers  to  be 
developed  (small,  medium,  large)  ? 

—  What  approach  to  logistics  compatibility  is  required? 

•  Box 

•  Module  F^ 

•  Build  to  print. 

—  How  often  is  the  list  regenerated;  i.  e. ,  what  is  the  basis  for 
deciding  when  to  redevelop  computers  ? 
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—  What  are  the  pertinent  technology  trends;  how  are  they 
measured? 

—  Should  the  development  process  leading  to  certification 
be  funded  by  the  Navy? 

—  How  many  developers  are  required  or  to  be  allowed? 

—  What  should  be  the  actual  certification  process  ? 

•  Acquisition  process 

—  Quantity  guarantees  to  producers 
—  Procurement  for  production 

•  Multiyear  funding 

•  Requirements  contract 

—  How  many  producers  should  be  established? 

—  What  influence  should  the  parameters  of  LCC,  reliability 
and  maintainability,  and  hardware  cost  play  in  ILS  concepts, 
development,  production,  and  acquisition  priorities  ? 

—  What  must  be  structured  to  promote  a  competitive 
environment? 

•  Market  size/commitment 

•  Multiple  funded  developments 

—  What  are  the  elements  of  "standardization"  critical  to 
accreditation? 

•  Policy  mandates 

•  ISA  standard. 

•  Accreditation  roles 

—  Funding  process/responsibility 
—  Integration  of  operational  needs  from  users 
—  Planning  process 

•  What  basis  ?  LCC  ? 

•  Integration  of  requirements  for  market  size  projections 

•  Who  manages  development  versus  production? 

•  Commodity  procurement  process  ? 

•  Who  certifies  the  computers  ? 


2.  3  STUDY  METHODOLOGY 


Having  defined  those  factors  that  a  study  of  accreditation  must 
address,  the  study  methodology  depicted  in  Figure  2-3  was 
established.  The  methodology  focused  on  three  major  analyses: 

•  Life  Cycle  Cost  -  represents  measured  benefit  to  the  Navy 

•  Profitability  -  represents  risk  and  return  of  investments 
to  industry 

•  Acquisition  policies  -  key  elements  necessary  to  the  con¬ 
cept  of  accreditation. 

Thus,  the  study  methodology  examines  elements  necessary  to  de¬ 
velop  a  viable  accreditation  policy  acceptable  both  for  the  Navy 
and  to  Industry. 
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As  a  basis  for  the  three  analysis  areas,  input  data  was 
gathered  on 

•  Computer  technology  trends/projections 

•  Processor  configurations  (small,  medium  and  large) 

—  Physical/performance  characteristics 

—  Development  cost 

—  NRSU  costs  vs.  production  rate 

•  Government  costs 

—  Production  management 

—  Development  management 

•  Market  definition  for  Navy  shipboard  computers 

•  Navy  computer  procurement  policies 

—  Past  and  present 

—  DoD  standardization  programs. 

Then,  as  shown  in  Figure  2-3,  three  analyses  were 
performed  resulting  in  a  framework  for  accreditation  that 
addresses  the  factors  identified  from  the  scenario  con¬ 
siderations  examined.  Section  3  discusses  the  first  of  the 
input  data  areas  —  technology  trends  and  projections  for 
LCC. 


Figure  2-3.  Study  Methodology 
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Section  3 

TECHNOLOGY  CONSIDERATIONS 


The  rapid  advances  in  digital  electronic  technology  are  widely  recognized. 
Hand-held  calculator  price  trends  are  indicative  of  price/performance 
improvements  in  digital  technology.  Current  calculator  price  trends 
potentially  reflect  that  "discard"  could  be  a  cost-effective  means  of 
maintenance. 

An  understanding  of  these  dramatic  digital  technology  improvements 
leads  to  an  obvious  question:  How  can  the  Navy  capture  the  benefits  of 
advancing  digital  technology  (while  considering  the  constraints  of  logis¬ 
tics,  budget,  etc.)? 

An  answer  to  this  question  dictates  an  assessment  of  the  rate  of 
technology  improvement.  Caution  must  be  exercised,  however,  because 
there  are  really  two  rates  of  technology  growth:  device  improvements 
and  military  computer  improvements.  While  specific  devices  are  experi¬ 
encing  tremendous  rates  of  improvement  in  terms  of  reliability  and 
price/performance,  computers,  which  are  effectively  a  mixture  of  "old" 
and  new  technology,  are  improving  at  a  lesser  rate.  The  use  of  the  wrong 
rate  could  yield  erroneous  conclusions. 

This  section  examines  both  device  trends  and  computer  trends.  The 
computer  trends  are  used  by  the  Life  Cycle  Cost  analysis  (in  Section  4) 
to  examine  the  concept  of  periodic  redevelopment.  In  addition,  these 
same  trends  are  used  to  examine  various  possibilities  for  future  mainte¬ 
nance  concepts. 


3.1  DEVICE  TRENDS 

Processing  improvements,  geometric  scaling,  design  innovation,  market 
demands,  and  business  enthusiasm  have  provided  a  growth  rate  in  the 
semiconductor  integrated  circuits  industry  that  is  unparalleled  by  any 
other.  Memory  devices,  high-function  devices,  microprocessors,  and 
gate  array /masterslices  have  been  improving  in  gate  density  at  approxi¬ 
mately  40%  per  year,  a  doubling  of  density  every  2  years.  The  results 
of  this  growth  are  reflected  in  cost  and  reliability  improvements.  Costs 
have  been  declining  at  20%  to  30%  per  year,  and  reliability  has  been 
improving  at  a  rate  proportional  to  the  gate  density  growth;  i.  e. ,  40%  per 
year. 

The  gate  density  growth  rates  are  illustrated  in  Figure  3-1.  Note 
that  random  logic  TTL  (transistor-transistor  logic)  functions  have  not 
improved  as  dramatically.  The  apparent  reason  for  this  is  attributed  to 
the  lack  of  functional  growth  due  to  packaging  pin  restrictions.  E.  F.  Rent 
of  IBM  empirically  described  the  relationship  between  chip  gate  density 
and  I/O  pins. 
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No.  of  I/O  =  (Constant)  (No.  of  circuits)^ 


By  empirical  determination 
0  =  0.  5  to  0.  75 
Constant  =  2. 5  to  3. 5 

From  this  it  is  possible  to  determine  the  average  functional  gate 
density  for  a  16-pin  package  to  be  12.  The  IC  industry  now  recognizes 
this  as  a  problem,  and  is  pursuing  20-  and  24-pin  packages  for  random 
logic  functions.  This  will  allow  a  two  times  improvement  in  density. 
For  example, 

Constant  =  3.0 

0  =  0.625 
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Price  —  1979  Reference  Year  ($/gate) 


No.  of  usable  I/O  =  14,  No.  of  gates  =  12 
No.  of  usable  I/O  =  22,  No.  of  gates  =  25 

Cost  and  reliability  improvements  are  a  consequence  of  increasing 
the  gate  density  per  chip  and  improving  manufacturing  methods.  Cost 
experience  for  IBM  FSD's  military  logic  circuits  has  indicated  approxi¬ 
mately  a  20%  price  decline  per  year.  This  is  illustrated  in  Figure  3-2. 

Reliability  per  gate  has  improved  with  the  density  growth.  By  using 
RADC  MIL-HDBK-217C  and  Notice  1,  the  curve  illustrated  in  Figure  3-3 
was  generated.  The  reliability  shown  is  for  a  referenced  Navy  shipboard 
application.  Changes  in  environment  will  alter  this  curve.  More  severe 
environments  (higher  temperature,  corrosion,  vibration)  will  decrease 
the  reliability  of  circuits  and  shift  the  curve  up. 

Three  points  are  shown  on  the  curve  of  Figure  3-3  to  represent 
various  integration  levels .  They  are  the  average  level  currently  used 
in  box- level  designs,  the  2901  4-bit  CPU  slice,  and  the  68000  16-bit 
microprocessor.  From  this  chart,  it  can  be  concluded  that  designs 
incorporating  LSI  will  be  greater  than  three  orders  of  magnitude  more 
reliable  than  those  using  SSI. 


Figure  3-2.  Device  Cost  Trends 
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Failure  Rate  per  Gate  Hour 


Level  of  Integration 
(Equivalent  gates/chip) 


Figure  3-3.  Chip  Integration  as  a  Function  of  Reliability 


3.2  COMPUTER  TRENDS 

Technology  improvements  at  the  device  level  will  be  reflected  in  the 
design  of  new  computers.  While  the  maximum  cost  and  reliability  bene¬ 
fits  would  be  attained  by  using  the  highest  chip  integration  level  practical, 
several  factors  can  force  computer  designers  to  use  lower  integration 
levels.  They  include  the  demands  of  higher  performance,  use  of  multiple 
qualified  sources  for  devices,  and  short  production  runs. 

The  relationship  between  cost,  performance,  and  integration  is 
illustrated  for  commercial  computers  in  Table  3-1.  Trends  of  price/ 
performance,  performance,  and  reliability  for  military  computers  are 
illustrated  as  Figures  3-4,  3-5,  and  3-6,  respectively.  Note  that  per¬ 
formance  has  been  improving  at  approximately  the  same  rate  that  price/ 
performance  has  been  declining,  which  implies  a  relatively  flat  price 
trend.  Note  the  opposing  factors  of  performance,  integration  level,  cost, 
power,  etc.  This  implies  that  a  balanced  processor  design  is  required 
by  the  developer.  The  implications  of  this  are  that  performance  does 
indeed  dramatically  affect  cost. 

Reliability  improvement  of  6%  to  14%  per  year  has  been  realized  for 
IBM  FSD’s  military  computers.  The  growth  of  6%  per  year  represents 
the  observed  growth  of  computers,  which  includes  increasing  memory, 
performance,  and  function.  The  14%  per  year  growth  is  for  computers 
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Table  3-1.  VLSI  and  Computer  Implementation  Spectrum 


Examples  of  computer/technology  implementations 


MOSTEK 

8870 

INTEL 

8086 

LSI-11 

Burroughs 

380 

11/34 

(FP11-A) 

Raytheon 
RP  16 

IBM 

370 

VAX 

11/780 

Cray  I 

INTEL 

8048 

INTEL 

8080A 

Fairchild 

TT'U 

National 

IMP  16 

IBM 

Series/1 

Amdahl 
470  /6 

HP  1000 

CDC  5500 

r  o 

11.70 

Zilog 

Z80 

DG  Nova 

Motorola 

68000 

Microcomputer 

Microprocessor 

Two- to- four- 
chip 

microprocessor 

Multichip 

microprocessor 

TTL  bit 
slice 

TTL  gate 
arrays 

ECL  LSI 
custom 

MSI  TTL 

ECL  SSI 

(0. 1  mips)  Lower  performance  * - ►  Higher  performance  (100  mips) 


MOS  intensive  *— - - — — - ►  Bipolar  intensive 

VLSI* - _ ►  SSI 

Lower  cost  *  - - - - — . — - - — ►Higher  cost 

Note:  LSI  memories  span  whole  spectrum  of  computer  implementations 


REF:  R.  F.  Spencer,  Jr.,  "VLSI  and  Minicomputers, "  Compcon  78,  February  1978,  p.  20. 
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Figure  3-4.  Military  Computer  Price/Performance  Trends 
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Computer  Performance  (kops) 


32-bit 


Figure  3-5.  Military  Computer  Performance  Trends 


Figure  3-6.  Military  Computer  Reliability  Trends 
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normalized  for  constant  function  and  memory,  which  was  based  on  an 
analysis  to  determine  the  factors  which  influence  computer  reliability. 

The  basic  elements  of  a  computer  can  be  identified  as  CPU,  I/O, 
memory,  power  supply,  and  miscellaneous  (backpanels,  harness, 
switches,  connectors,  etc.). 

Table  3-2  identifies  a  'typical'  computer  mix  with  its  associated 
reliability  contributions.  This  data  is  representative  of  IBM  avionics 
computers,  using  SSI  and  MSI  vendor  TTL  logic  functions.  Within  each 
subgroup  lies  the  reliability  associated  with  either  the  semiconductor 
or  the  interconnection  system. 

The  failure  rates  of  pins  and  PC  board  plated-through  holes  have 
essentially  remained  constant  with  time,  whereas  the  reliability  of 
semiconductors  on  a  per  gate  basis  has  improved  directly  as  a  result 
of  the  integration  level.  (Refer  to  Figure  3-3.)  This  results  in  a  re¬ 
liability  improvement  for  the  CPU,  I/O  and  memory,  as  shown  in  Table 
3-2,  which  is  highly  dependent  on  the  circuit  integration  design.  The 
power  supply  is  relatively  unaffected  because  of  the  discrete  nature  of 
the  designs.  The  miscellaneous  items  represent  mechanical  intercon¬ 
nections,  which  also  tend  to  be  constant  with  time.  Consequently,  the 
estimated  weighted  effects  have  provided  a  14%  per  year  growth  of 
reliability. 

The  two  computer  growth  rates  of  price/performance  and  reliability 
have  been  used  in  a  Life  Cycle  Cost  model  to  determine  the  influence  of 
periodic  redevelopments  to  the  accreditation  concept.  These  growth  rates, 
of  16%  and  14%  per  year,  respectively,  are  based  on  historical  trends  and 
were  linearly  extrapolated  for  the  next  10  years.  (These  rates  assume 
fixed  functions.)  These  future  extrapolations  seem  reasonable  because  an 
order  of  magnitude  in  geometric  device  scaling  by  itself  is  yet  achievable. 
The  Life  Cycle  Cost  analysis  of  these  trends  is  treated  in  Section  4. 


Table  3-2.  Estimated  Failure  Distributions  for  a  General  Purpose 
Militaiy  Computer  (Assumes  Typical  I/O  Memory,  CPU  Mix) 


Basic  Computer  Elements 

Estimated  Reliability 
Growth/Year  (%) 

%  of  System 
Failure  Rate* 

CPU 

8,  random  logic 

26 

I/O 

8,  random  logic 

20 

Main  store 

40,  RAM 

24 

8,  random  logic 

10 

Power  supply 

Constant  =  0 

11 

Miscellaneous  (back- 
panels,  harness,  etc.) 

Constant  =  0 

9 

*14%/Year  Reliability  Growth  for  GP  Computers.  Normalized  for 
Functionality  and  Per  BIT  of  Memory. 
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Section  4 

LIFE-CYCLE  COST  ANALYSIS 


The  previous  section  identified  significant  trends  in  computer  reliability 
growth  and  cost/performance  improvement.  Clearly,  the  Navy  would 
like  to  capture  these  benefits  through  new  technology  infusion.  However, 
these  benefits  must  be  viewed  in  the  light  of  potentially  offsetting  logistics 
costs. 

This  section  uses  a  Life  Cycle  Cost  (LCC)  analysis  model  to 
examine  several  aspects  of  a  new  accreditation  policy.  The  an¬ 
swers  to  these  questions  are  helpful  in  the  formation  of  new  ac¬ 
creditation  policy. 

The  first  area  examined  involves  the  frequency  of  technology  in¬ 
troduction.  Specifically,  is  there  an  "optimal"  redevelopment  period? 
If  so,  are  the  savings  significant  compared  to  a  policy  of  no  (or  infrequent) 
redevelopment  ? 

Next,  competition  and  various  acquisition  strategies  are  reviewed. 

The  number  of  developers  and  the  number  of  producers  are  varied  to  see 
if  a  preferable  combination  exists. 

Finally,  various  analyses  are  performed  to  test  the  sensitivity  of 
the  conclusions  to  basic  model  assumptions;  i.  e.  ,  rates  of  cost  and 
reliability  improvement,  levels  of  logistics  support,  the  amount  of  com¬ 
petitive  savings,  and  learning  curve  effects. 


4.1  LIFE-CYCLE  COST  METHODOLOGY 

The  LCC  methodology  is  based  upon  establishing  a  Total  Program  Cost 
for  the  various  accreditation  alternatives.  The  Total  Program  Cost 
includes  Contractor  and  Government  development  costs  (multiple  costs 
if  multiple  developments),  logistics  acquisition  costs  (dependent  upon 
number  of  suppliers)  and  the  operation  and  support  costs  incurred  across 
a  15-year  use  period.  The  methodology  assumes  that  under  each  accred¬ 
itation  alternative,  computer  delivery  requirements  for  10  years 
would  be  met. 

The  methodology  used  in  the  LCC  analysis  is  shown  in  Figure  4-1. 

It  begins  with  the  establishment  of  baseline  configurations  for  three 
classes  of  machines,  defined  as  small,  medium,  and  large.  The  small 
machine  is  a  single  card,  under-the-covers  processor.  The  medium 
machine  is  roughly  of  the  AN/UYK-20  class.  The  large  machine  is 
roughly  of  the  AN/UYK-7  class.  Further  detail  on  these  processor  con¬ 
figurations  appears  in  Appendix  A. 

The  Total  Program  Cost  was  established  for  a  development  program 
starting  in  1979  for  each  of  the  three  classes  of  machines.  This  program 
cost  was  established  based  upon  an  acquisition  approach  reflecting  a 
single  developer/producer.  (Other  model  assumptions  appear  later  in 
this  section  and  in  Appendix  A. ) 
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Figure  4-1.  LCC  Analysis  Methodology 

The  technology  effects  were  then  integrated  into  the  cost  model. 
(These  effects  were  summarized  in  Section  3  as  a  cost  reduction  of  16% 
per  year  and  a  reliability  improvement  of  14%  per  year. )  This  is  depicted 
in  Figure  4-2.  The  reduced  cost  and  improved  reliability  results  in 
significant  overall  program  savings  if  the  program  start  is  delayed  to 
capture  the  technology  trends. 

Figures  4-3,  4-4,  and  4-5  summarize  the  Total  Program  Cost 
for  each  of  three  classes  of  computer.  These  figures  show  the  per¬ 
centage  of  program  cost  vs.  the  year  of  start  of  the  development 
activities.  For  each  configuration,  the  cost  elements  are  summarized 
as  follows: 

•  Production  Hardware  -  Reducing  with  the  rate  of  cost  improvement 

•  Spares  -  Reducing  with  the  combined  effects  of  cost  and  reliability 
improvements 

•  Recurring  Logistics  -  Reducing  with  the  rate  of  reliability 
improvements 

•  Other  Program  Costs  -  Costs  assumed  to  be  fixed,  including 
development,  etc.  ,  as  subsequently  identified. 

For  example,  the  cost  commitment  made  for  production  hardware 
and  operation  and  support  in  1989  would  be  20%  of  the  value  required  in 
1979  for  the  medium-class  computer  if  the  procurement  was  delayed  for 
10  years.  Although  delaying  the  procurement  is  impractical,  it  does, 
however,  point  to  the  question  of  whether  enough  savings  can  be  realized 
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Figure  4-2.  Projected  Reliability  and  Cost  Trends  Used  in  LCC 
Analysis  -  Function  Held  Constant 


Figure  4-3.  Total  Program  Cost  Components  -  Small  Machine 
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Percentage  of  15- Year  Program  Cost  Percentage  of  Total  Program  Cost 


110 


Figure  4-4.  Total  Program  Cost  Components  -  Medium  Machine 


Figure  4-5.  Total  Program  Cost  Components  -  Large  Machine 
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to  offset  multiple  development  costs  if  redevelopment  is  utilized  during 
the  10-year  production  cycle.  If  so,  a  viable  technique  is  to  define  a 
fixed  hardware  baseline  (standard)  for  a  shorter  production  run  and  then, 
on  a  scheduled  basis,  incorporate  the  latest  technology  within  form,  fit, 
and  function  constraints  at  the  computer  level. 

Thus,  the  concept  of  periodic  redevelopment  is  examined  to  evalu¬ 
ate  the  advantage  of  adopting  a  new  procurement  policy  of  introducing 
the  latest  technology  hardware  without  changing  the  form,  fit,  or  function 
of  the  computer.  The  basis  for  the  evaluation  of  the  redevelopment 
program  cost  is  depicted  in  Figure  4-6.  When  the  development  program 
is  initiated,  the  total  cost  commitment  reflected  by  the  available  tech¬ 
nology  base  is  made,  including  operation  and  support  costs.  If  no  re¬ 
development  takes  place,  and  the  total  production  program  is  10  years, 
this  commitment  is  equivalent  to  a  10-year  period  between  redevelopment 
and  is  indicated  as  such  on  Figure  4-6. 

The  logistics  costs  are  represented  by  the  production  hardware, 
spares,  and  recurring  logistics  costs.  When  redevelopment  is  ap¬ 
plied,  the  one-time  costs  (development  related)  are  incurred  again, 
and  the  logistics  costs  become  an  average  of  the  newer  and  older 
technologies. 

Therefore,  in  Figure  4-6,  the  Total  Program  Cost  is  depicted  as 
the  sum  of  two  functions:  (1)  the  development  investment  incurred  -  a 
cost  decreasing  with  the  years  between  application  of  new  technologies 


Figure  4-6.  Redevelopment  Effect  on  Total  Program  Cost 
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(number  of  developments  required  decreasing);  and  (2)  the  hardware  and 
15-year  operation  and  support  cost  commitment  made  in  satisfying  the 
total  acquisition  requirements  -  a  cost  increasing  with  years  between 
application  of  new  technologies  because  cost/reliability  benefits  are  not 
realized. 

Next,  procurement  options,  in  terms  of  the  number  of  developers 
and  the  number  of  producers,  are  analyzed.  Finally,  sensitivity  analyses 
are  performed.  The  sensitivity  of  the  conclusions  to  variations  in  tech¬ 
nology  trends  and  competitive  savings  is  tested. 


4.  2  LCC  MODEL  AND  ASSUMPTIONS 

The  LCC  model  computer  is  based  upon  a  model  equivalent  to  MIL-STD- 
1390B,  Appendix  C  and  the  Life-Cycle  Cost  Guide  for  Equipment  Analysis 
prepared  for  the  Naval  Material  Command  by  NWESA.  It  is  composed 
of  three  constituent  elements:  development,  investment,  and  support 
costs.  These  cost  elements  are  as  follows: 

•  Development 

—  Contractor 
—  Government 

•  Investment 

—  Prime  equipment  acquisition 
—  Initial  hardware  nonrecurring  start-up  support 
—  Acquisition  of: 

—  Support  equipment 
—  Supply  support 
—  Training 
—  Technical  data 

—  Government  program  management 

•  Support 

—  Corrective  maintenance 
—  Support  equipment  maintenance 
—  Supply  support 
—  Data  management 
—  Packaging  and  shipping 

The  development  costs  consist  of  Contractor  and  Government  cost. 

A  Contractor  development  cost  figure  was  established  for  each  class  of 
machine  and  was  maintained  as  a  fixed  cost  independent  of  year  of 
development.  Government  development  cost  was  estimated  at  one-half 
of  contractor  development  costs. 

The  investment  cost  is  comprised  of  four  major  elements:  acquisi¬ 
tion  of  prime  equipment  hardware;  nonrecurring  start-up  (NRSU)  costs; 
Government  program  management;  and  acquisition  of  support  equipment, 
training,  supply  support,  and  technical  data.  The  unit  hardware  cost 
was  established  for  each  class  of  machine.  The  cost  was  modified 
during  redevelopment  cycles  to  reflect  the  technology  and  cost  improve¬ 
ments  projected  during  that  time  period. 
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The  support  costs  encompass  five  major  areas:  corrective  mainte¬ 
nance,  support  equipment  maintenance,  supply  support,  data  manage¬ 
ment,  and  packaging  and  shipping.  To  compute  these  costs,  a  maintenance 
concept  and  operational  criteria  were  defined.  The  recurring  costs  were 
computed  for  the  discard  and  repair  alternatives  for  the  different  classes 
of  machines.  The  cost  for  the  large-  and  medium-scale  computers  was 
based  upon  a  cost-effective  discard  concept,  while  the  small-scale  com¬ 
puter  was  repaired  at  depot. 

In  this  study,  a  10%  competitive  savings  in  acquisition  cost  from 
multiple  developers/producers  was  assumed,  and  the  cost  elements  were 
summed  in  constant  dollars. 

No  software  effect  was  included  in  this  study  because  it  was  assumed 
that,  in  all  redevelopment  cases,  the  computers  would  remain  completely 
software  compatible  and  no  new  functions  would  be  added.  Table  4-1  high¬ 
lights  some  of  the  acquisition  cost  and  reliability  parameters  used. 
Appendix  A  provides  further  detailed  definition  of  how  the  assumptions 
and  inputs  were  derived  for  this  study. 


Table  4-1.  Acquisition  Cost/Quantity  Summary 


'~'^—-^Class 

Parameter 

Small 

Medium 

Large 

Initial  Acquisition  Cost 

$5k 

$50k 

$250k 

Projected  Quantities 

(10,000) 

(7,600) 

(2,020) 

Total  Acquisition  Cost 

$50M 

$380M 

$505M 

Initial  Reliability  (MTBF) 

50,000  h 

2, 000  h 

1,400  h 

4.  3  REDEVELOPMENT  ANALYSES  AND  RESULTS 


Five  major  analyses  were  performed  to  assess  the  effect  of  the  periodic 
redevelopment  concept  on  the  Total  Program  Life  Cycle  Cost: 

•  Effect  of  periodic  redevelopments 

•  Effect  of  acquisition  strategy  on  redevelopment 

•  Sensitivity  of  the  cost/reliability  projections 

•  Effect  of  competitive  savings 

•  Effect  of  learning  curve. 

4.  3.  1  EFFECT  OF  PERIODIC  REDEVELOPMENTS 

The  first  analysis  determines  the  effect  upon  the  overall  program  costs 
of  varying  the  years  between  redevelopment.  The  result  is  that,  based 
on  a  15-year  program  and  the  assumptions  that  reliability  improvement 
will  increase  at  a  14%  annual  rate  and  costs  will  decrease  at  an  annual 
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rate  of  16%,  it  is  most  attractive  to  redevelop  every  3-5  years  for  the 
medium  and  large  computers  and  every  5-7  years  for  the  small  com¬ 
puter,  This  is  shown  on  Figure  4-7. 

The  optimum  number  of  years  between  redevelopment  is  determined 
by  the  net  programs  savings  that  result  from  periodic  redevelopment. 

For  example,  for  the  medium-scale  computer,  the  development  cost, 
if  incurred  once  in  the  10-year  period,  represents  5%  of  the  Total 
Program  Cost.  With  two  developments,  the  development  costs  represent 
12%  of  the  Total  Program  Cost,  but  the  hardware  and  support  savings 
result  in  a  net  decrease  of  25%  in  the  Total  Program  Cost. 

The  optimal  period  for  redevelopment  of  the  medium-scale  computer 
is  approximately  3  years.  At  this  point,  the  development  costs  rise  to 
18%  of  the  Total  Program  Cost,  but  the  savings  result  in  a  decrease  of 
29%  in  the  Total  Program  Cost. 

Figure  4-8  and  Tables  4-2  through  4-4  summarize  how  these  results 
were  obtained.  Figure  4-8  illustrates  the  candidate  time  lines  associ¬ 
ated  with  the  multiple  redevelopments.  Tables  4-2,  4-3  and  4-4  show 
the  quantitative  values  of  the  program  cost  elements  for  the  three 
machine  classes  for  discrete  (one,  two  and  three)  developments.  The 
cost  savings  and  the  sensitivity  of  the  results  to  the  cost  assumptions 
can  be  obtained  from  these  figures  and  tables. 

It  can  be  seen  that  hardware  costs  are  reduced  as  a  direct  result  of 
introducing  newer  technology  at  a  lower  procurement  cost.  Spares  costs 
are  reduced  due  to  the  combined  effects  of  increased  reliability  and 
lower  procurement  costs.  Other  support  cost  are  reduced  as  a  result 
of  improved  reliability.  The  remaining  costs  stay  constant  and  are  con¬ 
sidered  as  development  costs. 

The  variation  in  the  optimal  point  between  the  three  classes  of  com¬ 
puters  is  a  function  of  the  development  cost  and  savings  realized.  For 
the  small,  medium,  and  large  classes  of  machines,  the  ratio  of  develop¬ 
ment  cost  to  Total  Program  Cost  was  12%,  5%,  and  8%,  respectively. 
Because  the  medium  class  has  the  lowest  relative  cost  ratio,  the  great¬ 
est  LCC  savings  results  for  this  class  of  computers. 

4.  3.  2  EFFECT  OF  ACQUISITION  STRATEGIES 

The  effect  that  the  number  of  developers  and  producers  has  upon  the 
Total  Program  Costs  was  analyzed  to  determine  an  optimal  accreditation 
approach.  The  acquisition  strategies  evaluated  included  (1)  one  developer, 
one  producer;  (2)  two  developers,  one  producer;  (3)  two  developers,  two 
producers;  and  (4)  three  developers,  three  producers. 

These  acquisition  strategies  are  depicted  in  Figure  4-9.  While  these 
strategies  are  shown  with  a  10-year  redevelopment  period,  other  rede¬ 
velopment  periods  were  also  evaluated. 
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Total  Program  Cost  (large/medium)  ($M) 


Figure  4-7.  Effect  of  Years  Between  Redevelopment 


One  Development 


Production  O&S 


Two  Developments 


Three  Developments 


5  10 

Years  into  Production  Program 

Figure  4-8.  Redevelopment  Time  Line 
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Total  Program  Cost  (small)  ($M) 


Table  4-2.  Small-Scale  Computer  Effect  of  Redevelopment 


One  Developer,  One  Producer, 

Constant  Function 

One  Development 

Two  Developments 

Three  Developments 

1st  Year 

5th  Year 

1st  Year 

3rd  Year 

7th  Year 

($  millions) 

($  millions) 

($  millions) 

($  millions) 

($  millions) 

($  millions) 

Hardware 

50.  0 

25.0 

10.  5 

16.  7 

9.3 

5.3 

Spares  cost 

7.4 

3.7 

2.  0 

2.  5 

1.  6 

1. 1 

Other  support  cost 

13.  0 

6.  8 

3.9 

4.  7 

3.4 

2.  5 

Development  cost 

1.5 

1.  5 

1.5 

1.5 

1.5 

1.  5 

Production  NRSU 

1.3 

1.3 

1.3 

1.  3 

1.3 

1.3 

Government  Development 

0.  8 

0.  8 

0.  8 

0.  8 

0.  8 

0.  8 

Government  Program  Office 

6.  0 

4.  8 

3.  8 

4.2 

3.  6 

2.  8 

Total/acquisition 

80.0 

43.  9 

23.  8 

31.  7 

21.  5 

15.3 

Total  program  cost 

80.  0 

67.  7 

68.  5 

Table  4-3.  Medium-Scale  Computer  Effect  of  Redevelopment 

One  Developer,  One  Producer, 

Constant  Function 

One  Development 

Two  Developments 

Three  Developments 

1st  Year 

5th  Year 

1st  Year 

3rd  Year 

7th  Year 

($  millions) 

($  millions) 

($  millions) 

($  millions) 

($  millions) 

($  millions) 

Hardware 

377.  6 

188.  8 

79.3 

125.  8 

70.  5 

40.  3 

Spares  cost 

362.  7 

191.  7 

42.  5 

134.  9 

49.  5 

18.  6 

Other  support  cost 

94.  8 

50.  8 

27.  0 

34.5 

22.  7 

15.1 

Development  cost 

10.  0 

10.  0 

10.  0 

10.  0 

10.  0 

10.  0 

Production  NRSU 

15.  0 

15.  0 

15.  0 

15.  0 

15.  0 

15.  0 

Government  development 

5.  0 

5.  0 

5.  0 

5.  0 

5.  0 

5.  0 

Government  program  office 

15.  0 

12.  0 

9.  5 

10.5 

9.  0 

7.  0 

Total/acquisition 

880.  1 

473.3 

188.3 

335.  7 

181.  7 

110.  0 

Total  program  cost 

880.  1 

661.6 

628.4 

Table  4-4.  Large-Scale  Computer  Effect  of  Redevelopment 
One  Developer,  One  Producer,  Constant  Function 


One  Development 

($  millions) 

Two  Developments 

1st  Year  5th  Year 

($  millions)  ($  millions) 

Three  Developments 

1st  Year  3rd  Year  7th  Year 

($  millions)  ($  millions)  ($  millions) 

Hardware 

511.1 

255.  6 

109.9 

171.3 

95.9 

54.  8 

Spares  cost 

360.  2 

216.  5 

46.1 

173.  0 

62.7 

23.2 

Other  support  cost 

70.4 

36.  6 

20.3 

25.4 

17.5 

12.  3 

Development  cost 

30.  0 

30.  0 

30.  0 

30.  0 

30.  0 

30.  0 

Production  NRSU 

18.  0 

18.  0 

18.  0 

18.  0 

18.  0 

18.  0 

Government  development 

15.  0 

15.  0 

15.  0 

15.0 

15.  0 

15.  0 

Government  program  office 

15.  0 

12.0 

9.5 

10.  5 

9.  0 

7.  0 

Total/  acquisition 

1.019.  7 

583.  7 

248.  8 

443.2 

248.1 

160.  3 

Total  program  cost 

1,019.  7 

832.5 

851.  6 
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Figure  4-9.  Acquisition  Strategies  Evaluated 

The  effect  on  total  program  cost  of  the  various  acquisition  strategies 
is  shown  on  Figure  4-10  for  the  medium-class  computer.  The  results 
indicate  that,  with  redevelopment  every  5  years  (near  the  optimal  point) 
only  small  program  savings  are  achievable  by  varying  procurement 
strategies.  The  Total  Program  Cost  for  one  developer,  one  producer 
closely  matched  that  of  two  developers,  one  producer  with  redevelopment. 
This  relatively  small  difference  (less  than  5%)  in  savings  results, 
even  with  an  extended  redevelopment  period.  This  indicates  the 
greater  importance  of  redevelopment  as  compared  to  procurement 
strategy. 

Total  Program  Costs  increase  when  two  developers,  two  producers 
are  introduced  into  the  model.  The  competitive  savings  realized  from 
competition  is  offset  by  the  duplicate  NRSU  cost  required  to  bring  on  an 
additional  production  facility.  Additional  Government  support  is  also 
required  to  support  the  second  producer,  which  further  offsets  the  com¬ 
petitive  savings.  When  three  developers,  three  producers  is  evaluated, 
the  increases  more  than  offset  the  savings.  Therefore,  more  than  two 
developers,  two  producers  is  not  considered  in  the  rest  of  the  analyses 
as  a  viable  acquisition  alternative. 

The  medium-class  computer  results  are  shown  in  Figure  4-10. 

The  other  classes  of  computers  have  similar  results,  and  are  re¬ 
viewed  in  the  summary. 
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•  With  redevelopment  every  5  years,  a  20% 
overall  program  savings  results 


Figure  4-10.  Effect  of  Number  of  Producers  and  Redevelopments, 
Medium-Scale  Computer 


4.  3.  3  SENSITIVITY  OF  COST/RELIABILITY  PROJECTIONS 

The  results  of  the  previous  analysis  (the  benefits  of  periodic  redevelop¬ 
ment)  were  based  on  capturing  the  projected  technology  growth  in  cost 
and  reliability.  In  this  section,  a  sensitivity  analysis  is  performed  to 
determine  what  effect  a  50%  reduction  in  cost/reliability  projections 
would  have  on  periodic  redevelopment  costs.  The  rate  of  reliability  im¬ 
provement  is  reduced  from  14%  per  year  to  7%  per  year.  This  reduction 
would  be  indicative  of  either  the  technology  projections  not  being  realized 
or,  alternately,  a  growth  in  machine  function  or  performance.  The  pre¬ 
vious  analysis  assumed  fixed  function  in  the  three  machine  classes. 

Figure  4-11  portrays  the  effect  on  hardware  and  support  costs  of 
the  various  rates  of  reliability  improvement  and  cost  reduction.  Decreas¬ 
ing  the  rate  of  reliability  improvement  has  less  of  an  effect  upon  total 
cost  than  decreasing  the  projected  rate  of  cost  reductions.  The  increased 
cost  is  reflected  in  the  production  hardware  and  spares,  which  represent 
the  major  program  cost.  By  reducing  the  reliability  growth  improve¬ 
ment,  one  increases  the  quantity  of  spares  required  to  support  the 
operational  program  as  well  as  the  recurring  maintenance  costs  to 
effect  the  additional  repairs.  The  decreased  rate  of  cost  reduction 
affects  the  total  cost  at  twice  the  rate  of  reducing  reliability  growth. 

The  effect  of  simultaneously  reducing  reliability  and  cost  savings 
rates  is  greater  than  the  sum  of  the  individual  items.  This  results 
because  the  spares  increase  in  both  quantity  and  cost.  The  sensitivity 
analysis  is  performed  utilizing  this  combined  rate. 

Results  of  the  analysis  show  that  redevelopment  with  reduced 
reliability  growth  and  cost  reduction  still  provides  significant  overall 
savings  and  that  one  producer  still  provides  the  lowest  total  program 
cost.  This  is  shown  in  Figure  4-12. 
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Figure  4-11.  Cost  and  Reliability  Sensitivity  Analyses 


Figure  4-12.  Sensitivity  Effect  of  Realized  Cost/Reliability  Growth, 
Medium-Scale  Computer 
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The  prior  analyses  on  redevelopment  assumed  the  functional  capa¬ 
bility  of  the  computer  was  held  constant.  As  stated  earlier,  the  reduc¬ 
tion  in  technology  trends  could  be  representative  of  increased  functional 
capability  and  performance,  which  would  lessen  the  technology  advantage 
realized.  Therefore,  even  with  some  functional  growth,  the  sensitivity 
analysis  indicates  that  a  policy  of  redevelopment  can  provide  program 
savings. 

4.3.4  EFFECT  OF  COMPETITIVE  SAVINGS  VARIATION 

This  section  investigates  the  effect  of  varying  competitive  savings. 
Although  the  exact  savings  from  competition  is  unknown,  a  10% 
savings  in  acquisition  cost  resulting  from  either  competitive  de¬ 
velopments  or  competitive  production  was  assumed  and  used  for 
the  previous  analysis,  then  parametrically  changing  this  savings 
to  20%. 

The  effect  of  varying  the  competitive  savings  from  10%  to  20%  for 
multiple  developers  is  shown  in  Figure  4-13.  The  basic  redevelopment 
conclusions  remain  unchanged.  The  second  analysis  evaluates  the  effect 
of  competitive  savings  for  two  producers .  Results  of  this  analysis  are 
summarized  in  Figure  4-14.  The  competitive  savings  of  multiple  pro¬ 
ducers  are  offset  as  a  result  of  the  additional  nonrecurring  startup 
costs  required  to  support  a  second  production  line  and  the  additional 
Government  program  management  needed  to  support  the  second  pro¬ 
ducer.  Again,  periodic  redevelopment  remains  viable. 

4.3.5  EFFECT  OF  LEARNING  CURVE 

The  effect  that  the  learning  curve  effect  has  upon  the  total  program  cost 
(given  multiple  producers)  was  also  analyzed.  A  90%  cumulative  cost 
improvement  curve  was  projected  for  the  total  production  quantity. 

To  obtain  the  maximum  benefit  of  cumulative  learning,  one  producer 
for  the  total  production  quantity  is  required.  If  multiple  producers 
are  introduced,  the  effects  of  the  cost  improvement  curve  would  not 
be  fully  realized. 

Dividing  the  production  quantity  among  two  producers  results  in  the 
last  half  of  the  production  savings  not  being  realized.  Based  on  a  90% 
curve,  this  amounts  to  an  increase  in  the  average  production  unit  cost 
of  10%  when  two  producers  are  utilized  over  the  projected  production 
quantity  of  10,000. 

Thus,  the  competitive  savings  for  multiple  producers  is  offset  by  a 
10%  increase  in  average  cost  because  cost  improvement  is  not  realized 
from  using  a  single  producer  for  the  total  production  quantity.  This  is 
summarized  in  Table  4-5.  When  the  learning  curve  effect  is  added  to 
the  assumed  competitive  savings,  the  effect  is  to  reduce  the  attractive¬ 
ness  of  multiple  producers,  as  is  quantitatively  defined  in  the  "Net" 
column  of  Table  4-5. 
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Percent  of  Total  Program  Cost  Percent  Qf  Jota|  Program 


Figure  4-13.  Sensitivity  Effect  of  Competitive  Savings,  Medium-Scale 
Computer,  Number  of  Developers 


Figure  4-14.  Sensitivity  Effect  of  Competitive  Savings  Medium-Scale 
Computer,  Multiple  Producers 


Table  4-5.  Learning  Curve  Effect 


Number  of 
Developers 

Number  of 
Producers 

Assumed 

Competitive  Saving 

Learning 

Curve 

Net 

1 

1 

0 

0% 

0 

2 

1 

-10%,  -20% 

0% 

-10%,  -20% 

2 

2 

-10%,  -20% 

+10% 

SR 

o 

T— 1 

1 

eR 

o 
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4.  3. 6  SUMMARY  OF  ANALYSES 


The  quantitative  results  of  the  five  major  analyses  are  summarized  in 
Tables  4-6  through  4-9.  These  results  have  been  evaluated  for  one  re¬ 
development  at  the  5-year  point,  which  is  near  optimal  for  the  three 
classes  of  computers. 

For  all  three  classes  of  computers,  the  following  observations  are 
made: 

•  Redevelopment  is  very  desirable  under  all  procurement  strategies 
(Table  4-6).  The  effect  of  redevelopment  for  the  three  classes  of  com¬ 
puter  are  graphically  depicted  in  figures  4-4  and  4-9.  Table  4-6  sum¬ 
marizes  these  figures  in  tabular  form.  The  effect  of  redevelopment  be¬ 
tween  the  5-year  point  (one  redevelopment)  and  the  10-year  point  (no 
redevelopment)  is  depicted  by  the  delta  column  in  Table  4-6,  reflecting 
the  savings  realized  with  redevelopment  under  each  of  the  various  pro¬ 
curement  strategies.  In  all  cases  significant  savings  resulted. 

•  Redevelopment  provides  the  greatest  Total  Program  Cost  savings: 
acquisition  strategy  can  provide  additional  savings  potential,  depending 
on  competitive  savings  (Table  4-7).  The  effect  of  redevelopment  in 
combination  with  each  of  the  procurement  strategies  is  summarized  in 
Table  4-7.  The  objective  is  to  evaluate  the  savings  realized  by  the  pro¬ 
curement  strategy  adopted.  This  is  presented  as  the  difference  between 
the  savings  realized  at  5  years  for  each  of  the  strategies  vs.  that  re¬ 
alized  by  a  single  developer/producer.  Figures  in  parentheses  repre¬ 
sent  negative  savings  (or)  increased  costs.  The  sensitivity  analysis 
results  on  the  effect  of  competitive  savings  are  also  presented  to  show 
the  potential  savings  of  20%  vs.  the  10%  reflected  in  the  baselines. 

These  are  also  depicted  in  Table  4-7. 

•  Two  developers  with  one  producer  provides  the  largest  total  program 
savings.  Table  4-7  summarizes  the  savings  potential  for  each  of  the 
procurement  strategies,  with  the  largest  potential  being  22%,  33%,  and 
23%  for  the  small,  medium,  and  large  computers,  respectively,  when 

a  two  developers,  single  producer  strategy  is  utilized  and  the  com¬ 
bined  savings  of  redevelopment  and  competitive  savings  of  20%  are 
realized. 

•  A  5-year  redevelopment  period  provides  a  manageable  time  period 
with  near  optimal  total  program  savings  (Table  4-8).  The  summary 
was  presented  by  evaluating  the  results  at  the  5-year  redevelopment 
interval.  The  effect  of  using  this  interval  instead  of  the  "optimal" 
interval  is  a  reduction  in  the  total  savings  realized.  This  effect  is 
shown  in  Table  4-8,  where  the  percentage  reduction  nonrealized  is 
presented.  The  year's  shift  in  the  redevelopment  interval  is  also 
summarized.  Comparison  of  the  savings  realized  at  the  5-year  rede¬ 
velopment  interval  vs.  the  savings  not  realized  indicates  that  the 
significant  advantage  of  redevelopment  is  not  dependent  upon  selection 
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Table  4-6.  Summary  of  Analysis  —  Redevelopment 


Percent  Savings  in  Total  Program  Cost 


Small  Computer 

Medium  Computer 

Large  Computer 

Acquisition 

Strategy 

With 

Redevelopment 

Without 

Redevelopment 

A 

With 

Redevelopment 

Without 

Redevelopment 

A 

With 

Redevelopment 

Without 

Redevelopment 

A 

1  developer, 

1  producer 

17% 

0% 

17% 

25% 

0% 

25% 

18% 

0% 

17% 

2  developers, 

1  producer 

16% 

4% 

12% 

27% 

7% 

20% 

16% 

4% 

12% 

2  developers, 

2  producers 

4% 

<3)% 

7% 

21% 

2% 

19% 

3% 

(5)% 

8% 

3  developers, 

3  producers 

12% 

m 

16% 

Observation:  Redevelopment  is  very  desirable  under  all  procurement  strategies. 


Table  4-7.  Summary  of  Analysis  —  Acquisition  Strategy,  Competitive 
Savings 


Percent  Savings  In  Total  Program  Cost 


Small  Computer 

Medium  Computer 

Large  Computer 

Acqulaltion 

Strategy 

With 

Redevelopment 
Every  5  Years 

Delta  for 
Acquisition 
Strategy  at  10% 
Competitive  Savinga 

Delta  for 
Acquisition 
Strategy  at  20% 
Competitive  Ravings 

With 

Redevelopment 
Every  5  Years 

Delta  for 
Acquisition 
Strategy  at  10% 
Competitive  Savings 

Delta  for 
Acquisition 
Strategy  at  20% 
Competitive  Savinga 

WUh 

Redevelopment 
Every  5  Yeara 

Delta  for 
Acqulaltion 
Strategy  at  10% 
Competitive  Savinga 

Delta  for 
Acquisition 
Strategy  at  20% 
Competitive  Savinga 

1  developer. 

1  producer 

17% 

- 

25% 

- 

- 

18% 

— 

2  developers, 

1  producer 

16% 

(1%) 

5% 

27% 

2% 

8% 

16% 

(2%) 

5% 

2  developers. 

2  producers 

4% 

(13%) 

(5%) 

21% 

(4%) 

3% 

3% 

(15%) 

(4%) 

ObaervatLons:  Redevelopment  provides  greateat  savings,  with  acqulaltion  strategy  providing 
aome  additional  savings  potential,  depending  on  competitive  savings. 


Two  developera.  one  producer  provider;  largest  potential  for  savings. 


Table  4-8.  Summary  of  Analysis  —  Five-Year  Redevelopment  vs. 
Optimal 


Variations  from  Minimum  with  5-Year  Redevelopment 


Acquisition 

Strategy 

Small  Computer 

Medium  Computer 

Large  Computer 

%  Savings 
Realized 
(optimal) 

A  From  Minimum 

%  Cost  Years 

%  Savings 

Realized 

(optimal) 

A  From  Minimum 

%  Cost  Years 

%  Savings 
Realized 
(optimal) 

A  from  Minimum 

%  Cost  Years 

1  developer, 

1  producer 

17 

0 

0 

25 

(4)  -2 

18 

a) 

-1 

2  developers, 

1  producer 

16 

0 

0 

27 

(2)  -1 

16 

0 

0 

2  developers, 

2  producers 

4 

(2) 

+1 

21 

(1)  -1 

3 

(1) 

+1 

3  developers, 

3  producers 

12 

(2)  +1 

Observation:  Five-year  development  period  provides  qualitatively  manageable  period 
with  near  optimal  total  program  savings. 
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Table  4-9.  Summary  of  Analysis  —  One  Half  of  Technology  Rates 


Percent  Savings 

Small  Computer 

Medium  Computer 

Large  Computer 

Acquisition 

Strategy 

With 

Redevelopment 
Every  5  Years 

Without 

Redevelopment 

A 

With 

Redevelopment 
Every  5  Years 

Without 

Redevelopment 

A 

With 

Redevelopment 
Every  5  Years 

Without 

Redevelopment 

A 

1  developer, 

1  producer 

6 

0 

6 

13 

0 

13 

6 

0 

6 

2  developers, 

1  producer 

7 

4 

3 

16 

7 

9 

4 

4 

0 

2  developers, 

2  producers 

(6) 

(3) 

(4) 

10 

2 

8 

(11) 

(5) 

(6) 

Observation:  Redevelopment  desirable  for  viable  acquisition  strategies  even  if 
projected  technology  benefits  are  not  fully  realized. 


of  the  optimal  point.  For  example  with  the  medium-class  computer, 
29%  (25%  +  4%)  savings  could  have  resulted  if  the  3-year  (5-2) 
redevelopment  period  was  adopted.  With  the  5-year  redevelopment 
interval,  86%  of  the  savings  are  realized  (25  -r  29). 
o  Redevelopment  is  desirable  as  a  viable  acquisition  strategy, 
even  if  projected  technology  benefits  are  not  fully  realized 
(Table  4-9).  The  effect  with  or  without  redevelopment  when  the 
total  technology  benefits  are  not  realized  was  depicted  graphical¬ 
ly  for  the  medium  class  computer  in  Figure  4-11.  This  is 
summarized  in  tabular  form  for  all  three  classes  of  computers 
in  Table  4-9.  The  small-  and  large-class  computers  are  more 
sensitive  to  achieving  the  projected  technology  improvements 
than  the  medium. 


4.4  QUALITATIVE  ASPECTS  OF  PROCUREMENT  STRATEGY 

The  results  of  the  Life  Cycle  Cost  analysis  show  that  the  procure¬ 
ment  strategy  is  far  less  important  than  redevelopment  in  terms  of  the 
savings  realizable.  There  are  many  considerations  and  approaches  in 
terms  of  the  procurement  strategy  that  cannot  be  reflected  in  the  quan¬ 
titative  analysis  performed  which  could  significantly  affect  the  overall 
attractiveness  of  a  particular  procurement  strategy. 

Although  a  concept  which  provides  for  redevelopment  clearly  pro¬ 
vides  significant  overall  program  savings,  the  best  procurement  strategy 
(number  of  developers,  number  of  producers)  to  implement  the  concept 
is  less  apparent.  In  fact,  the  different  procurement  strategies  only  differ 
by  5%  of  total  program  costs;  a  factor  of  the  order  of  the  accuracy  of  the 
analysis.  Therefore,  the  exact  procurement  strategy  should  be  selected 
by  other  than  quantitative  analysis.  This  section  summarizes  the  quali¬ 
tative  aspects  for  the  various  strategies  considered. 
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4.4.1  SINGLE  VS.  MULTIPLE  DEVELOPERS 


The  first  consideration  is  the  number  of  developers.  The  results  of 
the  Life  Cycle  Cost  analysis  indicate  that  for  all  classes  of  computers, 
either  one  developer  or  two  developers  with  a  redevelopment  period  of 
5  years  is  attractive  on  an  LCC  basis,  but  there  is  no  cost  advantage 
in  considering  more  than  two  developers. 

The  advantages  of  two  developers  over  one  include: 

•  More  realistic  fixed  price  production  competitions  can  be  completed 
following  the  completion  of  the  development  program. 

•  Technology  risks  can  be  taken  in  the  development  phase,  enabling 
competitive  technology  advantages  to  be  assessed  prior  to  the  production 
decision  by  the  Contractor  and  the  Navy. 

•  Performance  achievements  between  designs  can  be  evaluated,  par¬ 
ticularly  from  the  standpoint  of  reliability,  maintainability  and  support 
features,  which  enables  evaluation  of  the  Life  Cycle  Cost  targets  estab¬ 
lished. 

•  Logistics  support  elements/requirements  (e.  g. ,  technical  manuals 
and  spares  provisioning),  which  are  part  of  the  production  program, 

still  retain  the  competitive  influences,  providing  incentive  for  contractors 
to  minimize  these  items  and  their  cost. 

These  items  appear  to  represent  a  significant  savings  potential  to  the 
Government,  and  offset  the  risks  on  the  part  of  both  industry  and  the 
Government. 

The  major  advantage  of  a  single  developer  is  the  minimization  of 
Government  administrative  and  development  evaluation  costs.  This  cost 
penalty  can  be  recovered  with  the  assumed  10%  cost  savings  realizable 
from  the  competitive  effects.  Therefore,  the  recommendation  to  utilize 
two  developers  appears  to  have  advantages. 

4.4.2  SINGLE  VS.  MULTIPLE  PRODUCERS 

The  questions  regarding  the  number  of  producers  is  more  complex. 

Three  alternatives  are  identifiable: 

•  Single  producer  -  analyzed  previously 

•  Two  producers  -  analyzed  previously 

•  Leader/follower  -  not  specifically  analyzed. 

The  leader/follower  concept  for  the  production  phase  would  fall  be¬ 
tween  the  single  producer  and  two  producer  alternatives.  Specifically, 
the  cost  for  leader/follower  would  be  more  than  for  a  single  producer, 
because  additional  NRSU  costs  would  be  required,  but  it  would  be  less 
than  for  two  producers,  because  logistics  resources  would  not  be  dupli¬ 
cated  (because  leader/follower  implies  identical  support  resource  re¬ 
quirements  build  to  print). 
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The  advantages  of  a  multiple  producer  strategy  are 

•  Potential  additional  resources  to  expand  production  in  the  case  of  a 
national  emergency 

•  Less  sensitivity  of  national  security  to  the  success  (technologically 
or  business  posture)  of  a  single  company 

•  Potential  additional  competitive  savings  as  a  result  of  head-to-head 
competition  following  the  initial  production  award. 

These  advantages  (achieved  through  either  two  producers  or  leader/ 
follower)  are  offset  by 

•  Potential  increased  cost  in  production  due  to  learning  curve  effects 
(particularly  with  leader/ follower,  where  technological  differences  cannot 
offset  learning  effects) 

•  Additional  Navy  support  resources  required  (e.  g. ,  training  of  data 
system  technicians,  Navy  management,  technical  supervision)  particu¬ 
larly  with  multiple  producers,  where  simultaneous  delivery  and  support 
requirements  would  occur  for  two  different  computers 

•  Duplication  of  initial  startup  and  schedule  problems  in  R&D  (due  to 
introduction  of  a  new  machine  as  a  result  of  simultaneous  producers) 

•  Reduced  investment  recovery,  de- emphasizing  to  some  extent  addi¬ 
tional  industry  capital  investment. 

The  results  of  the  analysis  performed  indicated  that  a  single  pro¬ 
ducer  strategy  was  slightly  preferable  from  a  cost  standpoint.  From  an 
evaluation  of  the  qualitative  factors,  the  increased  burden  on  DS  person¬ 
nel  may  be  of  critical  importance.  If  so,  multiple  developers  and  a 
single  production  supplier  appear  to  be  preferable. 


4.5  QUALITATIVE  ASPECTS  OF  MAINTENANCE  CONSIDERATIONS 

One  of  the  limitations  of  Life  Cycle  Cost  analyses  is  the  necessary 
assumption  that  the  trained  people  required  for  maintenance  are  avail¬ 
able.  As  identified  in  the  final  report  of  the  Navy  Embedded  Computer 
Review  Panel  (NECRP),  Appendix  D,  the  requirements  for  data  systems 
technicians  are  projected  to  exceed  the  available  quantities  of  personnel, 
as  reflected  in  Figure  4-15.  These  projections  were  based  upon  the  dis¬ 
tributable  manning  projected  into  the  future  to  reflect  the  increasing 
complexity  of  new  and  complicated  equipment  requiring  highly  trained 
maintenance  expertise  due  to  the  introduction  of  UYK-7s  and  UYK-20s 
into  the  fleet.  The  results  of  the  NECRP  study  clearly  indicate  that: 

1.  Effective  operational  utilization  of  deployed  equipment  will  be 
severely  impacted  if  the  required  maintenance  levels  are  in  fact  re¬ 
quired  and  not  available. 

2.  Incorporation  of  technology  advances  to  the  level  required  to 
mitigate  the  potential  problem  hasn't  occurred.  If  maintenance  simplifi¬ 
cation  were  achieved  through  technology  advances,  then  the  manpower 
requirements  with  the  additional  equipment  being  fielded  might  remain 
constant. 
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Figure  4-15.  Data  Systems  Technician  Distributable  Manning 

Computers,  by  themselves,  do  not  dictate  the  personnel  level  load¬ 
ing  required  into  the  future,  but  the  host  systems  utilizing  the  em¬ 
bedded  computer  installations  may.  Because  of  the  expressed  concern 
by  the  Navy  about  data  systems  technician  requirements,  the  following 
paragraphs  review  the  results  of  the  study  as  applicable  to  computers, 
and  suggests  some  other  areas  of  consideration. 

One  approach  to  reduce  the  need  for  skilled  maintenance  personnel 
onboard  ship  is  to  design  the  equipment  with  such  a  high  reliability  that 
it  does  not  fail  during  the  length  of  the  mission.  The  need  for  any  onboard 
maintenance  would  thus  be  eliminated.  Any  maintenance  would  be  deferred 
to  the  end  of  the  cruise.  Qualified  Navy  or  contractor  personnel  could 
then  provide  required  maintenance  at  a  central  location. 

To  achieve  an  absolute  failure-free  equipment,  of  course,  requires 
a  design  with  infinite  reliability.  A  design  point  was  arbitrarily  selected 
as  a  0.  95  probability  of  completing  the  mission  without  a  failure,  i.  e. , 

5%  of  the  time,  a  failure  would  occur. 

The  required  equipment  reliability  to  achieve  such  a  condition  is 
shown  in  Figure  4-16.  To  achieve  maintenance-free  equipment  for  a 
90-day  mission  requires  an  equivalent  MTBF  of  43,  000  hours.  This  re¬ 
quirement  is  contrasted  with  the  present  MTBF  of  2,  000  hours,  which 
yields  a  probability  of  success  of  0. 34.  Projecting  the  current  reliability 
of  2,  000  hours  forward  with  a  reliability  growth  rate  of  14%  a  year  as 
determined,  which  is  the  military  computer  reliability  history  for  fixed 
functions  in  Section  3,  still  does  not  provide  the  required  reliability. 
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Probability  of  Success 


90-day  mission 


Figure  4-16.  Mission  Maintenance- Free  Computer 

As  seen  from  Figure  4-16,  a  0.  75  probability  of  success  is  achieved 
in  10  years.  Clearly  a  simplex  (nonredundant)  design  is  not  avail¬ 
able  in  the  near  future  to  achieve  a  mission  maintenance- free 
design. 

Some  form  of  redundancy  must  be  implemented  to  achieve  a  fault- 
tolerant  design.  Figure  4-17  parametrically  examines,  as  a  function 
of  reliability  growth  rate,  some  redundant  designs  to  achieve  the 
0.95  probability  of  success  required  for  no  on-board  maintenance. 
Device  reliability  trends  have  improved  at  a  significantly  higher 
rate  than  the  box  reliability. 

Even  a  duplex  redundant  design  is  not  sufficient  to  achieve  the 
requirement.  Figure  4-17  suggests  that  the  approach  is  to  design 
redundancy  at  internally  partitioned  levels  within  the  computer  to 
achieve  the  requirement.  In  fact,  the  greater  the  partitioning, 
the  lower  the  redundancy  required.  An  effort  of  additional  develop¬ 
ment  and  equipment  cost  penalties  are  incurred  to  implement  re¬ 
dundancy.  Test  equiment  and  maintenance  skills  at  the  maintenance 
site  will  also  be  further  complicated  by  a  redundant  design  approach. 

The  effectiveness  of  this  solution  to  the  total  problem  is  dependent 
upon  more  than  just  the  computer,  but  also  the  reduced  maintenance 
capability  of  the  host  system.  Therefore,  prior  to  specific  recommen¬ 
dations,  the  host  systems  must  be  evaluated  in  terms  of  their  ability  to 
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Rate  of  Computer  Reliability  Growth 
(percent/year) 


Figure  4-17.  Time  in  Years  Until  Mission  is  Maintenance  Free 

be  designed  as  fault  tolerant.  Such  a  study  should  consider  the  extent  of 
potential  shore  maintenance  requirements. 

Another  consideration  to  reduce  maintenance  skill  levels  is  to 
evaluate  various  options  for  the  level  of  repair.  Alternate  repair  con¬ 
cepts,  such  as  sparing  at  the  box  level,  could  possibly  reduce  the  required 
maintenance  skills.  For  the  medium-class  computer,  the  baseline  con¬ 
figuration  is  evaluated  against 

•  The  computer  being  returned  to  depot  (only  computer  unit  spares  on 
ship) 

•  The  computer  repaired  through  assembly  level  replacement,  with 
the  assembly  returning  to  depot 

•  The  computer  repaired  through  assembly  level  replacement,  with 
the  assembly  being  discarded. 

These  various  maintenance  alternatives  effects  on  total  program  cost 
as  a  function  of  the  year  of  development  start  are  depicted  in  Figure 

4-18. 

The  results  of  the  analysis  for  the  medium-scale  computer  indicated 
that  the  most  cost-attractive  approach  was  discard  of  the  module.  The 
computer  being  returned  to  depot  was  the  most  costly,  with  the  major 
cost  being  the  number  of  computer  box  spares  required.  With  the  cost 
and  reliability  improvements  projected,  the  cost  penalty  for  the  depot 
repair  concept  for  the  computers  is  significantly  reduced.  Therefore, 
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Hardware  &  Support  Cost 
for  15  Years 


Year  of  Development  Start 


Figure  4-18.  Alternate  Repair  (Medium-Scale  Computer) 

in  the  future  (=10  years)  this  higher  level  of  maintenance  might  be  feasible, 
and  can  provide  a  means  for  reducing  the  requirement  of  data  specialist 
skilled  personnel  onboard  ship. 

The  large-scale  computer  was  also  investigated  for  alternate  repair 
concepts.  A  significant  cost  penalty  is  incurred  by  sparing  this  class 
machine  at  the  box  level,  such  that  the  concept  is  impractical.  Future 
studies  should  investigate  partitioning  this  machine  into  smaller  re¬ 
placeable  units  to  make  this  repair  concept  more  economically  feasible. 

The  preceding  consideration  could  encompass  the  use  of  a  Reliability 
Improvement  Warranty  approach  when  the  computer  was  returned  to 
depot  for  repair.  This  approach  has  proven  successful  in  the  commer¬ 
cial  airline  industry  and  also  on  selected  items  in  the  Navy  inventory. 
Usually,  a  higher  level  assembly  is  specified  as  the  removable  item  with 
less  sophisticated  fault  isolation  techniques.  This  sealed  assembly  is 
then  returned  to  a  depot  for  subsequent  maintenance  activity. 

A  cost  penalty  is  incurred  for  sparing  more  expensive  assemblies  in 
the  inventory.  However,  this  cost  penalty  is  balanced  by  reduction  in 
the  procurement  and  training  of  qualified  personnel.  This  approach  re¬ 
duces  the  incidence  of  induced  failures  and  erroneously  removed  hard¬ 
ware.  A  significant  rate  of  60%  of  field  returns  has  been  attributed  to 
this  fact  from  field  depot  return  history. 
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It  is  also  recommended  that  the  Navy  undertake  further  study  of  fault 
tolerance  through  distributed  systems  or  internal  partitioning,  not  only 
at  the  processor  but  also  at  the  host  system  level  to  determine  if  within 
the  next  5  years,  such  a  concept  should  be  considered  as  a  part  of 
accreditation  of  embedded  computers. 


4.6  CONCLUSIONS 


The  results  of  the  Life  Cycle  Cost  analysis  indicate  that  significant  savings 
in  the  Total  Program  Costs  for  embedded  computers  could  be  realized  if 
an  accreditation  approach  was  incorporated  and  periodic  redevelopments 
were  adopted.  The  Total  Program  Cost  for  future  Navy  shipboard  com¬ 
puters  was  estimated  to  be  about  $2  billion,  and  if  an  accreditation  ap¬ 
proach  based  upon  periodic  redevelopments  to  accommodate  technology 
changes  were  adopted,  a  savings  of  approximately  25%  could  result,  re¬ 
ducing  the  estimated  cost  to  $1.  5  billion.  Selection  of  an  optimum  pro¬ 
curement  strategy,  implied  from  the  cost  analysis  to  be  two  developers 
and  one  producer,  would  provide  additional  savings  due  to  the  additional 
competitive  effects  in  the  market.  These  savings  were  found  to  be  less 
significant  than  the  savings  from  redevelopment,  but  would  further  reduce 
the  estimated  program  cost  from  $1.5  to  $1.4  billion. 

The  conclusions  were  based  on  assuming  a  fixed  function  computer 
set,  so  that  the  technology  benefits  were  not  adding  to  the  complexity  of 
hardware  in  the  field,  but  instead  were  directed  at  simplifying  the  cur¬ 
rently  planned  program  requirements.  The  integration  of  this  accredita¬ 
tion  concept  into  current  Navy  procurement  policy  is  a  significant  departure 
from  current  practices,  where  the  primary  motivating  factor  for  a  change 
is  enhancement  of  performance  attributes.  However,  the  results  indicate 
that,  even  when  allowing  for  performance  enhancements  or  additional  func¬ 
tion,  Total  Program  Costs  could  still  be  reduced  to  1.  8  billion  dollars  with 
redevelopment . 

The  significantly  increasing  effect  of  logistics  support  costs  on  Total 
Program  Costs  has  been  identified,  and  is  an  increasingly  important  input 
to  development  engineering  for  new  designs. 

The  major  areas  not  addressed  in  the  analyses  were  software  effects 
and  the  effects  of  personnel  considerations  beyond  active  maintenance  time 
on  the  embedded  computers.  These  issues  are  difficult  to  assess  at  the 
embedded  computer  level,  and  require  that  analyses  be  performed  at  the 
host  system  or  platform  level.  Adopting  an  accreditation  policy  of  re¬ 
development  would  not  affect  the  support  system,  if  adequately  planned, 
and  may  in  fact  provide  additional  benefits,  among  which  are  increased 
fault  isolation  capability  and  increased  reliability. 

One  may  view  the  current  standardization  activities  as  a  system  that 
allows  for  a  constantly  changing  base  via  ECP  activity.  The  accredita¬ 
tion  concept  is  viewed  as  a  system  with  planned,  competitively  established, 
technological  enhancements  every  5  years.  The  overall  effect  is  expected 
to  be  more  manageable  and  beneficial  to  operational  capability. 
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Section  5 

PROFITABILITY  INCENTIVES  FOR  COMPETITION 


One  of  the  objectives  of  the  accreditation  study  was  to  induce  competition 
in  the  Navy  computer  market.  The  preceding  Life  Cycle  Cost  analysis 
addressed  the  attractiveness  of  competition  to  the  Navy.  The  attractive¬ 
ness  to  the  computer  developers/producers  of  the  business  opportunities 
which  arise  from  an  accreditation  policy  must  also  be  considered.  Unless 
the  policy  can  generate  sufficient  competitive  interest,  accreditation  will 
not  be  effective. 

The  Navy  has  in  its  control  a  number  of  items  that  affect  the  prof¬ 
itability  of  shipboard  computer  procurements.  These  include  develop¬ 
ment  funding,  the  maximum  permitted  profit,  and  the  degree  of  com¬ 
petition.  While  total  computer  requirements  may  be  relatively  fixed, 
the  manner  in  which  these  requirements  are  divided  between  producers 
also  affects  profitability.  This  division  can  be  both  in  parallel  (the 
number  of  producers)  and  in  serial  (the  period  of  redevelopment).  A 
viable  accreditation  policy  must  create  a  proper  balance  of  these 
considerations. 

Just  as  the  Navy  has  numerous  decision  criteria  other  than  cost 
for  evaluating  a  proposal  (e.g. ,  operational  effectiveness,  integrated 
logistics  support  (ILS),  supplier  risk),  a  potential  developer/producer 
has  numerous  decision  criteria  other  than  profitability  when. evaluating  a 
business  opportunity.  These  include  the  availability  of  personnel,  con¬ 
sonance  of  the  opportunity  with  business  goals,  project  risk  (technical  and 
schedule),  the  availability  and  cost  of  capital,  follow-on  potential,  and 
the  flexibility  allowed  to  meet  the  contract  requirements. 

While  all  of  these  factors  are  of  importance,  their  relative  importance 
varies  from  one  firm  to  the  next,  and,  within  a  single  firm,  according  to 
the  current  needs  of  the  business.  For  these  reasons,  a  firm  may  be  will¬ 
ing  to  compromise  on  one  factor  to  obtain  a  benefit  in  another.  For  example, 
faced  with  a  surplus  of  engineering  talent,  a  firm  might  consider  a  relatively 
unprofi table  opportunity  to  be  quite  attractive.  Or  a  firm  might  consider  a 
relatively  unprofitable  opportunity  to  be  an  attractive  entrance  into  a  new 
market. 

It  is  important  to  recognize,  however,  that  the  profitability  aspect 
cannot  be  ignored  indefinitely.  In  the  long  run,  firms  must  work  on  a 
profitable  basis  or  go  bankrupt.  For  these  reasons,  this  study  analyzes 
the  profitability  aspects  of  future  Navy  computer  procurements.  In  addi¬ 
tion,  these  factors  listed  (e.g. ,  availability  of  personnel)  do  not  readily 
lend  themselves  to  a  priori  analysis. 


5. 1  PROFITABIIITY/INVESTMENT  MODEL 

Many  models  can  be  used  to  evaluate  investment  opportunities.  For 
analysis  of  DoD  business,  these  models  are  often  complicated  by 
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considerations  such  as  funding  sources  (e.g. ,  the  relative  pro¬ 
portions  of  IRAD  funds,  investment  dollars,  capital).  Because 
the  future  markets  on  which  this  analysis  is  based  are  only 
loosely  defined,  and  because  there  is  no  insight  into  contract 
specifics,  a  simple  model  was  required  to  deal  with  the  problem 
on  a  cash  flow  basis  only. 

This  analysis  uses  two  simple  measures  of  "profitability": 
the  Internal  Rate  of  Return  (IROR),  which  is  sometimes  referred 
to  as  Return  on  Investment  (ROI),  and  Payback.  IROR  is  a  per¬ 
centage  measure  of  the  overal  "profitability"  of  the  investment; 
it  is  analogous  to  the  interest  earned  on  a  savings  account.  The 
payback  period  is  not  truly  a  measure  of  profitability.  Rather,  it 
is  a  measure  of  risk,  because  it  tells  the  investor  how  long  it  will 
be  before  he  or  she  breaks  even.  Firms  are  clearly  interested  in 
both  measures:  a  project  that  is  highly  profitable  overall  but  that 
does  not  break  even  for  8  years  may  not  be  attractive. 

The  model  treats  investments  and  profits  on  a  cash  flow  basis. 
Investment,  in  this  case,  is  the  computer  development  cost  funded 
by  the  supplier.  Profits  are  the  markups  on  production,  produc¬ 
tion  nonrecurring  startup  (NRSU),  and  on  that  portion  of  the  com¬ 
puter  development  funded  by  the  Navy. 

The  internal  rate  of  return  considers  the  cash  flows  over  the 
life  of  an  investment: 


I  Now  Year  I  Year  2  Year  N 


0  12  N 

(l+i)  (1+i)  (1  +  i)  (1+i) 


where  each  A  represents  an  annual  cash  flow.  The  negative  sign 
of  A0  signifies  that  A0  is  a  cash  outflow  (investment). 

The  IROR  is  defined  to  be  that  value  of  i  which  causes  the  net 
cash  flow  line  to  sum  to  zero.  The  time  value  of  money  is  taken  into 
account  in  that  a  dollar  received  in  year  2  is  less  valuable  than 
a  dollar  received  in  year  1.  This  is  simply  because  the  higher 
exponent  of  the  denominator  for  year  2  reduces  the  ability  of  a 
dollar  earned  in  year  2  to  offset  the  investment. 

The  Payback  measure  is  simply  the  time  period  for  which  the 
profits  exactly  equal  the  initial  investment.  That  is,  the  Payback 
period  is  that  value  of  t  such  that 


A0  A1  +  A2  +  ‘  '  At 

If  the  cash  inflows  are  equal,  that  is 


A 


1 


an  +  A> 


then,  the  payback  period  is  simply 

A 

payback  _  0 

period  A 
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The  IROR  and  Payback  are  computed  for  various  market  scenarios. 
The  data  used  for  the  total  computer  requirements  and  program  costs  is 
consistent  with  the  data  used  for  the  Life  Cycle  Cost  analysis.  Because 
that  analysis  suggests  that  there  is  an  optimum  redevelopment  interval 
of  between  3  to  7  years,  this  analysis  considers  a  5-year  market  period 
and  has  cut  the  total  10-year  Navy  projected  requirements  in  half.  The 
spares  percentages  are  derived  from  the  LCC  analysis.  These  data  are 
shown  in  Table  5-1. 

Table  5-1.  Data  Used  in  Profitability  Analysis 


Program  Costs 


Machine 

Size 

Development 
Cost  ($M) 

NRSU  ($M)  Rate 

Single  (units/ 

Supplier  mo) 

NRSU 
($M)  per 
Supplier, 
Two 

Suppliers 

Rate 

(units/ 

mo) 

Small 

1.5 

1.3 

90 

1.2 

45 

Medium 

10 

15 

60 

10' 

30 

Large 

30 

18 

20 

15 

10 

Total  Requirements  for  5  Years 

Initial  Acquisition 

Spares  (%) 

Unit 

Total 

Machine 

Cost 

Cost  Single 

Two 

Size 

Units 

($K) 

($M)  Supplier 

Suppliers 

Small 

5,  000 

5 

25 

L5 

25 

Medium 

3,  800 

50 

190  65 

100 

Large 

1,010 

250 

253  65 

100 

5. 1. 1  MARKET  SCENARIOS 

Four  different  market  scenarios  are  considered  in  this  analysis  (see 
Figures  5-1  and  5-2).  Each  scenario  begins  with  a  proposal  phase 
which  is  followed  by  two  or  three  development  awards.  After  develop¬ 
ment  is  complete,  a  competition  is  held  to  select  one  or  two  producers. 
In  the  two-producer  scenarios,  each  producer  has  one-half  of  the  total 
production  requirements  for  5  years;  i.  e. ,  they  produce  in  parallel. 

At  the  time  of  proposal,  each  prospective  bidder  must  make  a  bid/ 
no-bid  decision,  based  (in  part)  on  a  profitability  assessment.  To 
make  this  assessment,  each  bidder  must  estimate  the  expected  portion 
of  the  total  available  production.  Each  bidder  is  assumed  to  have  an 
equal  probability  of  winning.  The  expected  portion  of  the  total  available 
production  is  equal  to  the  probability  of  winning  times  the  expected 
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Award 
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Figure  5-1.  Candidate  Acquisition  Timelines,  Two  Developers 


Proposals 


Development 

Award 


Production 

Award 


5-year  production) 

_ I 


Figure  5-2.  Candidate  Acquisition  Timelines,  Three  Developers 
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value  of  that  win  (either  the  whole  production  quantity  or  one-half  of  the 
total  quantity).  These  calculations  are  shown  for  the  four  market  scena¬ 
rios  in  Table  5-2.  These  expected  portions  of  the  total  available  produc¬ 
tion  are  used  in  the  profitability  analysis.  Note,  however,  that  winners 
exceed  their  expectations  and  losers  have  a  greater  loss. 

Table  5-2.  Best  Available  Investment  Information  at  Time  of  Proposal 


Candidate  Scenario 


Expected  Portion  of 


Number  of 
Developers 

Number  of 
Producers 

Pr 

(win) 

X 

E 

(win) 

Total  Available 
Production 

3 

1 

1/3 

X 

1 

1/3 

2 

1 

1/2 

X 

1 

1/2 

3 

2 

2/3 

X 

1/2  = 

1/3 

2 

2 

1 

X 

1/2  = 

1/2 

Assumptions 


1.  Proposers  have  equal  probability  of  winning. 

2.  No  investment  until  development  awards  are  announced. 


5.1.2  CRITIERIA  FOR  ACCEPTABILITY 

To  determine  what  constitutes  an  "attractive"  business  opportunity,  it 
is  necessary  to  establish  cutoffs  for  IROR  and  Payback.  There  are  no 
universally  accepted  cutoffs;  "minimally  acceptable"  varies  with  business 
conditions,  inflation,  the  risk-taking  posture  of  the  individual  firm,  and 
many  other  considerations. 

For  this  analysis,  20%  has  been  selected  as  the  minimally  acceptable 
IROR.  This  is  based  on  an  examination  of  the  current  lending  rates.  If 
a  firm  must  pay  15%  for  investment  funds,  surely  it  must  earn  an  ex¬ 
pected  return  somewhat  greater  than  15%  for  bearing  the  risk  of  the 
investment. 

A  minimally  acceptable  Payback  is  more  difficult  to  estimate,  but 
it  clearly  must  be  based  on  an  estimate  of  the  technically  viable  lifetime 
of  the  product.  If  a  computer  were  expected  to  be  obsolete  (i.  e. ,  non¬ 
competitive)  in,  say,  5  years,  then  reliance  on  revenues  for  many  years 
beyond  5  is  risky.  This  analysis  assumes  minimally  acceptable  pay¬ 
back  periods  of  3,  4,  and  4  years  for  the  small,  medium,  and  large 
machines,  respectively.  The  lengthening  of  the  payback  periods  is 
based  on  the  assumption  that  larger  machines  have  a  longer  competitive 
viability  (because  of  their  increased  development  time  and  cost). 


5-5 


5.1.3 


MODEL  ASSUMPTIONS 


The  model  used  has  a  number  of  simplifying  assumptions: 

•  All  costs  are  incurred  and  all  revenues  are  realized  at  the  end  of 
each  year. 

•  Development  costs  are  incurred  in  year  0. 

•  Production  NRSU  costs  are  incurred  in  year  1. 

•  Production  revenue  occurs  in  five  equal,  annual  amounts. 

•  Multiple  suppliers  produce  in  parallel  over  the  full  5-year  time 
period  and  equally  share  the  market. 

•  A  hardware  price  reduction  (to  the  Navy)  of  10%  or  20%  will  occur 
through  competition,  but  the  percentage  will  not  increase  as  a  function 
of  the  number  of  competitors.  Both  percentages  are  calculated  in 
the  model. 

These  assumptions  are  used  to  facilitate  calculations. 

Table  5-3  is  an  example  of  a  cash  flow  scenario  examined  by  the 
model.  This  table  shows  the  cash  inflows  and  cash  outflows  for  the 
development  and  production  of  a  large-class  machine  by  two  suppliers. 

It  takes  market  and  cost  data  from  Table  5-1.  It  assumes  a  10%  price 
break  to  the  Navy  (resulting  from  competition)  and  an  8%  markup  (profit) 
by  the  suppliers.  Spares  are  at  the  100%  level. 

Cash  flows  are  summed  in  this  table  to  provide  a  yearly  cash  flow 
line.  This  cash  flow  line  is  used  by  the  IROR  and  Payback  formulas. 

Table  5-3.  Cash  Flow  Example _ 

Cash  Flows  Per  Supplier,  $M 

_ Year  0  Year  1  Year  2  Year  3  Year  4  Year  5 

Investment 

Development 
cost  (30. 0) 

Revenues 

Production 

NRSU 


(8%  of  $15M) 

Production, 

initial 

acquisition 

(8%  of  $126  M, 

1.2 

less  10%) 

Spares 

9.1  9. 1 

9.1 

9.  1 

9.1 

(@  100%) 

9.  1  9.  1 

9.1 

9.1 

9.1 

Net  cash  flow  (30.  0) 

19.4  18.2 

18.2 

18.2 

18.2 

Large  machine,  two  producers,  10%  price  break, 
ment  funded  by  producers 

8%  markup,  develop- 
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5.2  PROFITABILITY/INVESTMENT  MODEL  RESULTS 


This  analysis  has  determined  those  combinations  of  Government  funding 
for  development  and  profit  on  production  that  will  provide  both  a  mini¬ 
mally  acceptable  Internal  Rate  of  Return  and  a  minimally  acceptable 
Payback  period.  This  was  done  for  each  class  of  machine  and  for  a 
varied  number  of  competitors  and  varied  price  break  (resulting  from 
competition).  Because  the  exact  amount  of  the  price  break  resulting 
from  competition  is  not  known,  both  10%  and  20%  price  breaks  were 
parametrically  calculated. 

The  results  of  this  analysis  are  shown  in  Figures  5-3  through  5-5 
for  the  small-,  medium-,  and  large-class  machines,  respectively.  All 
of  the  points  on  each  line  represent  acceptable  business  opportunities 
(i.  e. ,  they  meet  the  minimally  acceptable  IROR  and  Payback  criteria) 
to  the  supplier(s). 

To  help  in  understanding  these  curves,  consider  the  two-developer 
band  for  the  large  machine  (Figure  5-3)  at  10%  price  reduction.  Each 
producer  requires  both  a  20%  minimum  IROR  and  a  Payback  period  of 
no  more  than  4  years.  The  computer  requirements  (initial  acquisition 
and  spares) ,  development  costs,  and  production  NRSU  costs  are  as 
shown  previously  in  Table  5-1.  If  the  producers  were  to  have  an  8 
percent  profit,  a  Navy  investment  of  approximately  $30  million  in  de¬ 
velopment  funding  would  be  required  to  make  this  investment  attractive. 
At  a  16%  profit,  the  scenario  is  attractive  with  approximately  $18  million 
of  Navy  development  funding. 

Consider  next  the  band  for  three  developers  and  20%  price  break. 

For  this  scenario,  if  the  producers  have  an  8%  profit,  a  total  Navy  in¬ 
vestment  in  development  funding  of  approximately  $40  million  is  re¬ 
quired  to  make  the  business  opportunity  attractive  to  two  producers. 

This  development  funding  is  assumed  to  be  split  equally  between  the 
suppliers.  At  a  16%  profit,  approximately  $25  million  of  development 
funding  is  required. 

For  three  developers,  even  larger  amounts  of  development  funding 
are  required.  Similar  interpretations  apply  to  the  small-  and  medium- 
machine  scenarios. 


5.  3  PROFITABILITY/INVESTMENT  MODEL  CONCLUSIONS 


The  most  important  conclusion  to  be  drawn  from  this  analysis  is  that, 
in  general,  there  is  seldom  sufficient  return  on  investment  to  attract 
industry  for  unfunded  development.  Hence,  the  Navy  must  fund  a  por¬ 
tion  of  the  computer  development  costs.  The  amount  of  this  funding  is 
reduced  to  the  extent  that  higher  profit  rates  are  permitted.  At  profit 
rates  of,  say,  10%,  funding  of  approximately  $1.  5  million,  $2  million, 
and  $35  million  are  required  for  the  small,  medium,  and  large  machines, 
respectively,  to  provide  adequate  profitability  to  two  developers. 
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Legend: 

No.  developers,  No.  producers,  price  reduction; 
e.g.,  3,1,10% 


3.0 
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Navy  Investment  in 

Development 

($M) 

2.0 

($1.5M 
development 
cost  per 
Contractor) 
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1r  20% 
2,  20% 


1,  20% 
2,  20% 
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Figure  5-3.  Small-Machine  Scenarios  Which  Provide  20%  IROR, 
3 -Year  Payback 


Minimum 
Navy  Investment 
in  Development 
($M) 

($10M  development 
cost  per  Contractor) 


Legend: 

No.  developers.  No.  producers,  price  reduction; 
e.g.,  3,1,  10% 


15 


10 


5 


— L 

2 

Percent  Profit  on  Development  and  Production 
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1,  20% 
2,  20% 


Figure  5-4.  Medium- Machine  Scenarios  Which  Provide  20%  IROR, 
4-Year  Payback 
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No.  developers,  No.  producers,  price  reduction; 
e.g.,  3,1,10% 
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Figure  5-5.  Large-Machine  Scenarios  Which  Provide  20%  IROR, 
4-Year  Payback 

The  foregoing  analysis  has  assumed  that  there  is  no  technical  risk, 
no  schedule  risk,  and  no  risk  of  cancellation.  Clearly,  adding  these  risk 
considerations  of  the  Government  market  further  diminishes  industry 
incentive  to  invest.  As  a  result,  the  Navy  investments  identified  above 
must  be  even  higher  than  stated. 

It  is  important  to  recognize  that  the  markets  which  are  defined  here 
are  the  total  markets.  They  represent  the  total  sales  that  the  producer(s) 
can  expect,  including  spares.  At  the  end  of  the  5-year  period,  the  ac¬ 
creditation  cycle  begins  anew,  and  the  existing  computers  will  probably 
not  have  the  proper  technology  base  to  viably  compete.  For  this  reason, 
producers  cannot  afford  to  take  relatively  unprofitable  contracts  with  the 
hopes  of  additional  future  sales  to  enhance  profitability. 


5.4  COMPETITIVE  PRICE  REDUCTIONS  VS.  ADDITIONAL  DEVELOPMENT  COSTS 

The  addition  of  competition  results  in  additional  costs  for  development. 
Competition  also  is  expected  to  provide  a  price  savings  on  production  to 
the  Navy.  It  is  desirable  to  examine  the  ability  of  competitive  price 
savings  to  offset  the  additional  development  costs. 
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Table  5-4  provides  a  simple  analysis  to  make  this  comparison. 

The  additional  costs  of  having  more  than  one  producer  are  shown,  as 
are  the  assumed  savings  resulting  from  competition  (for  both  10%  and 
20%).  Once  again,  the  savings  resulting  from  competition  are  arbitrary 
estimates;  no  insight  as  to  the  true  value  of  those  savings  is  inferred. 

The  price  reductions  due  to  competition  can  be  seen  to  significantly 
offset  the  additional  cost  of  multiple  developments.  Savings  of  10%  to 
20%  could  fund  between  one  and  three  developments,  depending  on  Navy 
priorities. 


Table  5-4.  Payback  Based  on  Competition 


Production 
Revenue  ($M) 

Production  Price  Reduction 

Development 
Cost  ($M) 

10%  ($M) 

20%  ($M) 

25  (small) 

2.5 

5.0 

1.5 

190  (medium) 

19.0 

38.0 

10 

253  (large) 

25.3 

50.6 

30 
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Section  6 

COMPUTER  ACQUISITION  STRATEGIES 


6.1  INTRODUCTION 


The  majority  of  the  tactical  shipboard  computer  systems  deployed  within 
the  present-day  fleet  can  be  traced  back  to  the  development  and  acquisi¬ 
tion  concepts  employed  by  the  Navy  since  the  late  1960's.  The  procure¬ 
ment  practices  employed  range  from  noncompetitive  selection  of  sole- 
source  development  and  production  suppliers  to  competitive  selection  of 
a  development  source,  with  follow-on  production  continuing  with  the 
same  supplier.  (See  Figure  6-1.) 

Current  1980  procurement  plans  call  for  the  award  of  dual  develop¬ 
ment  contracts,  following  a  multiple- source  competition.  The  succeed¬ 
ing  production  phase  of  the  procurement  will  introduce  some  form  of  the 
leader/follower  procurement  concept. 

The  AN/UYK-7,  AN/UYK-20,  and  the  AN/AYK-14  acquisitions 
illustrate  the  practices  carried  out  throughout  the  preceding  decade. 

The  AN/UYK-7  computer  development  contract  was  awarded  on  a  non¬ 
competitive  basis,  and  as  a  result  of  financial,  technical,  and  time 
restraints,  production  follow-on  contracts  have  continued  to  be  awarded 
on  a  noncompetitive  basis  through  the  present  time. 

The  AN/UYK-20,  developed  in  the  early  1970's,  followed  a  similar 
procurement  pattern.  The  single  development  contract  resulted  from  a 
competitive  procurement  approach;  noncompetitive  production  contracts 
followed.  The  sole  source  production  concept  remains  in  force  today. 

The  AN/AYK-14  computer,  a  current  standard  for  Navy  avionics 
applications,  was  awarded  to  a  single  development  contractor  following 
a  multiple- source  competition.  Preproduction  requirements  continue  to 
be  supplied  by  the  development  contractor.  Current  procurement  plans 
for  production  requirements  call  for  the  early  initiation  of  a  leader/ 
follower  concept,  wherein  production  requirements  will  be  competed 
between  two  established  sources.  Annual  quantity  requirements  would 
be  shared  between  the  two  suppliers. 

Single  R&D  Development  Production 

proposal  contractor  v  contractor  AN/UYK-7 


Multiple  R&D 
proposals 


Development 

contractor 


Production 

contractor 


AN/UYK-20 


Multiple  R&D 
proposals 


Dual  development 
contractors 


Production 

contractor 


Leader 

Follower 


NECS 


Figure  6-1.  Evolution  of  Acquisition  Strategies 
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The  Navy  Embedded  Computer  System  (NECS),  currently  in  the 
formulative  RFP  stage,  has  the  specified  goal  of  achieving  increased 
operational  capabilities  and  lower  Life  Cycle  Costs  while  simultaneously 
avoiding  logistic  obsolescence.  The  acquisition  plan  projected  would 
involve  multiple  development  contracts.  Preliminary  plans  indicate 
that  the  sponsoring  agency  will  decide  on  a  competitive  production  pro¬ 
curement,  reflecting  some  form  of  the  leader/follower  approach. 

The  accreditation  acquisition  strategy  to  be  described  is  a  further 
evolution  of  the  preceding  procurement  approaches.  It  is  intended  to 
enable  the  Navy  to  fulfill  its  computer  needs,  through  a  process  of 
accreditation,  provided  a  specified  level  of  performance,  reliability, 
sparing,  and  maintenance  can  be  accomplished. 

The  acquisition  strategy  depicted  in  Figure  6-2  provides  for  the 
solicitation  of  development  phase  proposals  from  multiple  industrial 
sources.  The  computer  specifications  prepared  by  the  Navy  would  be 
at  the  highest  functional  level  possible  to  allow  technical  innovation  and 
alternate  solutions  by  all  potential  development  suppliers.  A  form,  fit, 
and  function  (F3)  level  requirement  at  the  box  level  would  be  the  goal. 
Realization  of  the  F3  principle  would  reduce  development  costs  by  pro¬ 
viding  sources  able  to  accommodate  their  own  design  and  manufacturing 
techniques. 

Following  a  Navy  selection  procedure,  multiple  development  con¬ 
tracts  would  be  issued  to  the  successful  bidders.  The  results  of  the 
development  program  would  be  verified  by  an  accreditation  test  program 
established  by  the  Navy  to  determine  the  acceptability  of  the  developed 
computers.  Successful  demonstration  of  all  essential  requirements 
would  establish  the  development  contractor  as  an  accredited  source  and 
a  viable  contender  for  subsequent  production  contract  awards. 
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Figure  6-2.  Tactical  Computer  Accreditation  Strategy 
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6.2  CONSIDERATIONS 


As  stated  in  Section  2,  a  thorough  and  long-range  planning  function  is 
necessary  to  establish  an  effective  acquisition  program  throughout  the 
development  and  production  phases  of  computer  accreditation  program. 
The  outcome  of  the  planning  stage  must  result  in  a  procurement  plan 
capable  of  operating  within  the  bounds  of  acquisition  regulations  cur¬ 
rently  established  within  the  U.  S.  Navy  and  Department  of  Defense. 

To  satisfy  the  preceding  requirement,  the  procurement  plan  must 
provide 

•  A  clear  definition  and  understanding  of  technical  requirements  and 
operational  needs 

•  An  evaluation  of  Life  Cycle  Cost  projections  in  relation  to  program 
affordability 

•  Realistic  production  commitments  over  a  planned  period 

•  Procurement  policies  for  multiple  sources. 


6.  3  THE  ACQUISITION  SCENARIO 

The  acquisition  structure  depicted  in  Figure  6-3  should  provide  the  Navy 
with  a  basic  framework  for  future  long-term  computer  development  and 
production  efforts.  To  ensure  achie\ement  of  a  common  computer 
requirements  base  and  a  configuration  level  acceptable  for  carrying  out 
many  diversified  applications,  centralized  control  of  the  planning  and 
procurement  activity  is  a  primary  requisite. 

The  recommended  vehicle  for  use  throughout  the  embedded  com¬ 
puter  accreditation  process  is  a  Central  Acquisition  Agency  to  carry  out 
the  tasks  outlined  in  Figure  6-3. 

To  provide  an  adequate  focus  on  the  accreditation  program  and  to 
relieve  the  "computer"  from  competing  for  funding  support  with  other 
elements  of  a  designated  system,  appropriations  for  this  vital  element 
•  should  be  separated  and  controlled  outside  the  individual  system  man¬ 
ager's  function.  The  resulting  autonomous  status  would  relieve  the 
Agency  from  the  dependency  on  weapon  system  funding  allocations. 

Undue  influence  by  one  user  or  potential  user  would  be  eliminated, 
enabling  the  Agency  to  structure  a  development  and  production  program 
most  beneficial  to  all. 

The  initial  task  of  the  Agency  would  be  to  identify  all  newly  planned 
tactical  computer  applications  within  the  fleet  for  a  prescribed  duration. 
A  10-year  prospective  in  each  performance  class  would  satisfy  this 
requirement.  Operational  specifications  would  be  defined,  along  with 
reliability  and  operational  goals. 

The  request  for  proposal  would  be  prepared  for  the  development 
phase(s)  of  the  near-term  efforts,  utilizing  existing  Navy  and  Depart¬ 
ment  of  Defense  acquisition  regulations.  Thorough  planning  in  this  area 
would  be  essential  to  ensure  a  wide  range  of  interest  with  industry. 
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Development  Phase 


•  Requirements  definition 

—  Review  of  platform  requirements 
—  Definition  of  common  base,  options 
—  Preparations  of  specification 

•  Industry  solicitations 

—  RFP  preparation 
—  Evaluation  criteria  established 
—  Source  selection,  contract  awards 

•  Accreditation 

—  Test  definition 
—  Test  performance 
—  Certification  of  sources 

Production  Phase 

•  Requirements  definition 
—  Individual/cumulative 

program  needs  vs  schedules 
—  Contract  formation 
—  Multiyear  contracting 
—  Requirements  type  contract 

•  RFP  preparation 

•  Solicitation  of  accredited  sources 

•  Evaluation,  selection 

•  Contract  award 

•  Configuration  management 

Figure  6-3.  Acquisition  Approach 

Industry  should  then  be  invited  to  review  and  comment  on  draft 
copies  of  the  proposal  request.  Such  preliminary  reviews  would  provide 
the  Navy  an  insight  into  the  interest,  recommendations,  and  ability  of 
industrial  sources  to  respond  and  eventually  participate  in  the  develop¬ 
ment  effort.  The  final  version  of  the  request  for  proposal  would  include 
the  pre-established  Navy  criteria  to  be  used  during  the  evaluation  of  all 
industrial  submittals. 

The  selection  process  carried  out  by  the  Agency  should  result  in 
multiple  industrial  development  efforts.  The  scope  of  the  multiple- 
source  effort  should  allow  the  competitive  process  to  continue  between 
highly  rated,  competent  sources  during  the  development  phase.  The 
culmination  of  the  development  effort  would  be  the  demonstration  and 
test  of  the  development  computer  hardware  to  determine  accreditation 
status. 

The  production  program  concept  outlined  in  Figure  6-3  is  intended 
to  promote  the  use  of  a  small  number  of  computer  types  for  system 
applications.  The  acquisition  approach  continues  to  emphasize  the  role 
of  the  Central  Acquisition  Agency  in  identifying  and  coordinating  all  com¬ 
puter  requirements  for  the  production  phase.  Source  selection  and  con¬ 
tract  formation  continue  at  the  Agency  level. 
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Again,  the  Agency  must  determine  the  most  viable  approach  to  be 
used  during  the  competition  among  the  accredited  sources.  Current 
defense  acquisition  regulations  provide  guidelines  for  the  alternate 
methods  of  contracting  available  and  appropriate  for  use  under  the  pro¬ 
duction  accreditation  concept.  A  competitive  proposal  and  selection 
activity  between  all  accredited  development  sources  would  result  in  the 
selection  of  a  single  production  source. 

A  multiyear  type  contract  is  recommended  for  use  in  the  production 
acquisition  stage.  This  contract  approach  is  suitable  when  a  viable 
market  has  been  established,  along  with  definitive  delivery  schedules 
for  computers  (supplies)  within  a  specified  class.  The  elements  of  this 
contractual  approach  are  outlined  in  DAR  1-322  and  include  the  following: 

•  A  projection  of  requirements  covering  a  period  of  up  to  5  years 

•  Contract  provisions  covering  protection  of  the  Contractor  against 
loss  resulting  from  cancellation 

•  Maintenance  of  the  competitive  environment  among  potential 
industrial  sources. 

The  multiyear  procurement  approach  provides  an  equitable  contract¬ 
ing  vehicle  to  all  parties  to  the  acquisition  process.  Industry  is  pre¬ 
sented  with  a  definitive  production  base  under  which  management  can 
determine  reasonable  investment  and  risk.  The  Government  Procure¬ 
ment  Agency  realizes  the  advantage  of  better  cost  distribution  by  allow¬ 
ing  nonrecurring  costs  to  be  distributed  over  large  numbers  of  units. 

The  multiyear  funding  approach  is  beneficial  because  it  allows  potential 
sources  to  consider  committing  capital  investments  that  could  result  in 
decreased  costs  to  the  Government. 

The  current  Defense  Acquisition  Regulation  outlining  the  use  of  the 
multiyear  procurement  approach  contains  a  specified  limitation  of  $5 
million  as  the  maximum  amount  available  in  the  event  of  contract  ter¬ 
mination,  to  cover  contractor  nonrecurring  costs.  Consideration  should 
be  given  to  a  legal  revision  to  increase  the  current  dollar  limitation 
covering  the  recovery  of  contractor  nonrecurring  costs.  This,  along 
with  appropriate  economic  price  adjustment  provisions,  would  further 
strengthen  the  industrial  source  base  available  to  future  Navy  accredita¬ 
tion  programs. 

An  alternate  production  contractual  approach  is  the  requirement- 
type  contract.  This  contractual  approach,  as  described  in  DAR-3-409.  2, 
would  give  the  Navy  a  vehicle  to  enter  the  production  phase  when  quan¬ 
tities  and  delivery  schedules  cannot  be  projected  definitively.  The  re¬ 
quirements  contract  would  provide 

•  Provisions  for  placement  of  "orders"  under  the  base  contract  within 
the  agreed  upon  contractual  period 

•  Commitment  of  funds  under  each  order  as  released. 

The  indefinite-type  requirements  contract  provides  the  procuring 
agency  with  a  vehicle  to  combine  requirements  where  feasible  into  one 
quantity  procurement,  effecting  a  potential  cost  savings,  while  simul¬ 
taneously  maintaining  inventories  at  a  desired  (nonsurplus)  level.  To  be 
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acceptable  among  the  potential  sources,  the  contract  must  provide 
meaningful  minimum  and  maximum  quantities  to  be  acquired  to  allow 
industry  to  make  fruitful  management  investment  decisions. 


6.4  ON  GOING  CONCEPT  ANALYSIS 

In  addition  to  administering  the  specific  development  and  production 
phases  of  a  computer  acquisition,  an  important  function  of  the  Agency 
will  be  to  maintain  currency  within  the  computer  environment.  The 
dynamic  evolution  of  computer  technology,  the  influences  of  the  economy, 
the  performance  to  existing  plans,  all  influenced  by  changes  to  mission 
needs  and  requirements,  necessitate  a  continuing  emphasis  on  the 
planning  function.  During  the  production  phase,  and  in  anticipation  of 
redevelopment,  the  Central  Agency  must  be  tasked  to  review  accom¬ 
plishments  to  date  and  plan  toward  meeting  the  future  Navy  needs. 

In  reviewing  accomplishments,  the  facts  surrounding  the  planning 
efforts  associated  with  the  previous  development  cycle  should  be 
analyzed.  What  method  could  be  improved?  What  steps  could  be  taken 
to  assure  more  accurate  or  earlier  data?  Was  the  technology  concept 
sound  and  achievable?  Were  the  proper  resources  sufficiently  utilized? 
The  answers  to  these  questions  should  influence,  in  a  positive  manner, 
the  planned  redevelopment  activity. 

Simultaneously,  the  anticipated  mission  needs  must  be  focused  on 
as  a  continuing  responsibility.  What  do  the  System  Commands  require, 
what  is  the  commonality  of  these  requirements,  and,  where  needs  differ, 
how  or  can  they  be  brought  together?  This  internal  effort  is  crucial,  but 
full  benefit  can  only  be  derived  when  integrated  with  an  understanding  of 
technology  availability. 

The  Agency  must  remain  abreast  of  what  will  be  available  from 
industry  during  the  redevelopment  time  period.  This  can  most  effective¬ 
ly  be  accomplished  by  initiating  studies  with  industry.  The  study  tasks 
should  define  the  desired  goals,  and  industry  should  respond  with  solu¬ 
tions  for  their  achievement  or  definitions  of  what  can  be  achieved  in  the 
various  technological  areas. 

This  concept  definition  activity  will  improve  the  future  by  building 
upon  lessons  learned.  It  will,  through  a  broad  base  involvement,  better 
define  what  is  available  from  industry,  which  translates  into  achievable 
and  affordable  technology  enhancement.  It  would  also  allow  industry,  in 
addition  to  the  current  producer,  to  remain  involved,  provide  its  ex¬ 
pertise,  and  plan  its  own  future  business  activities. 
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Section  7 

ADDITIONAL  CONSIDERATIONS 


While  factors  like  technology  trends,  redevelopment,  the  number  of  de¬ 
velopers  and  producers,  Life  Cycle  Cost  optimization,  and  an  acquisition 
framework  are  key  to  the  concept  of  accreditation,  a  number  of  other 
factors  should  be  integrated  into  a  workable  policy.  These  factors  include 

(1)  the  level  of  standardization  (e.g.,  build  to  print,  module  F  ,  box  F^), 

(2)  architecture  certification,  and  (3)  the  significance  of  commercial 
developments  are  addressed  in  this  section. 


7 . 1  LEVEL  OF  STANDARDIZATION 


If  the  Navy  decides  to  have  multiple  developers  and  producers  as  part  of 
an  accreditation  policy,  then  the  level  of  identicality  at  which  computers 
are  to  be  standardized  must  be  determined.  The  selection  involves  a 
tradeoff  of  numerous  factors . 

First,  Navy  objectives  or  requirements  for  standardization  must  be 
considered: 

•  Operational  software  transportability 

•  Support  software  compatibility 

•  Minimize  LCC  (e.g.,  hardware  cost,  spares  requirement,  and  training) 

•  Maintain  common  test  equipment 

•  Permit  technology  infusion 

•  Provide  reasonable  performance 

•  Maximize  system  availability. 

The  selection  of  a  standardization  level  affects  all  of  these  objectives 
and,  unfortunately,  no  one  level  of  standardization  solves  all  problems. 

The  basis  for  multiple-sourcing  of  computers  could  be  summarized 
as  follows: 

Obtain  the  greatest  "functional"  capability  per  dollar,  and  ensure 
that  this  functional  capability  will  always  be  available  (e.g.,  do  not 
allow  national  security  to  hinge  on  the  fortunes  of  one  company) . 

Consider  first  the  goal  of  achieving  the  greatest  "functional"  capability, 
which  could  be  expressed  in  terms  of  KOPS  of  performance,  bytes  of 
memory,  reliability,  channels  of  I/O,  etc.  A  periodic  redevelopment 
cycle  every  4  to  7  years  will  provide  significant  technology  infusion, 
regardless  of  the  level  of  standardization. 

Standardizing  on  the  Build-to-Print  level,  however,  limits  this  func¬ 
tional  improvement  to  a  single  new  design  and,  to  some  degree,  restricts 
competition.  Giving  suppliers  the  ability  to  meet  a  functional  require¬ 
ment  on  a  module  or  box  level,  in  the  best  way  that  they  know,  increases 
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the  probability  of  more  effective  designs.  The  higher  the  level  of 
definition  (box  F3,  in  this  case)  the  greater  the  flexibility  afforded 
a  developer/producer.  An  F3  level  of  standardization  would  permit 
the  program  manager  to  optimize  functional  capability  on  "per¬ 
formance"  parameters  (reliability,  throughput,  memory  capacity, 
etc. )  that  are  the  most  important.  In  addition,  the  higher  the  F3 
level  of  standardization,  the  greater  the  probability  that  more  "func¬ 
tional"  capability  would  be  available. 

7.1.1  COST  VERSUS  STANDARDIZATION  LEVEL 

Total  LCC  is  highly  dependent  on  the  level  of  standardization  and  the 
number  of  producers.  This  study  considers  how  cost  is  affected  by  the 
level  of  standardization  by  analyzing  the  major  cost  components  (soft¬ 
ware,  acquisition,  and  logistics)  separately. 

The  most  significant  of  these  is  software  costs.  The  primary  goal 
of  computer  standardization  is  the  containment  of  software  costs  by 
standardizing  on  an  instruction  set  architecture  (ISA).  This  provides  the 
benefits  of  support  software  compatibility  and  operational  software  trans¬ 
portability.  Note  that  all  three  standardization  levels  provide  a  standard 
ISA.  Test  software  used  for  diagnostic  purposes  is,  however,  unique  to 
the  particular  hardware;  thus,  F3  standardization  would  incur  higher 
costs. 

In  the  area  of  logistics  costs,  build  to  print  and  module  F3  have  ad¬ 
vantages.  They  provide  minimum  spares,  common  support  equipment, 
and  minimum  training  and  documentation.  This  is  not  true  of  box  F  . 

Acquisition  costs  must  be  divided  into  the  components  of  design, 

NRSU  and  recurring  costs  to  see  the  effects  of  a  standardization  level.  A 
single  final  design  under  the  build-to-print  approach  would  apparently 
result  in  the  lowest  design  costs.  However,  there  is  usually  a  develop¬ 
ment  competition  and  a  "fly-off"  between  competing  designs,  so  more 
than  one  design  is  actually  done.  Also,  the  additional  cost  of  generating 
and  maintaining  adequate  documentation  so  that  a  second  manufacturer 
can  build  the  first's  product  is  significant.  Therefore,  it  is  not  clear 
which  standardization  level  offers  the  lowest  design  cost. 

The  manufacturing  NRSU  costs  are  clearly  the  lowest  under  the  box 
F3  approach  because  the  producers  have  the  flexibility  to  use  their  own 
processes  and  tools.  Module  F3  would  require  additional  tooling  and  test 
equipment  to  handle  different  form  factors.  For  the  second  producer, 
build  to  print  would  require  even  further  expenditure  to  put  equivalent 
manufacturing  processes  in  place,  as  well  as  mold  existing  manufac¬ 
turing  operations  to  the  new  product. 

The  lowest  product  recurring  costs  should  be  obtained  under  the  box 
F3  approach  because  the  suppliers  are  given  the  most  latitude  to  meet 
requirements.  Both  module  F3  and  build  to  print  restrict  this  flexibility. 

In  summary,  just  the  costs  of  the  different  standardization  levels  do 
not  clearly  indicate  which  approach  is  the  best.  Historical  data  suggests 
that  logistics  cost  are  more  significant  than  acquisition  costs,  making 
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the  build-to-print  approach  more  attractive  on  a  cost  basis.  However, 
in  the  future,  technology  trends  show  that  reliability  will  continue  to 
improve,  resulting  in  reduced  O&M/logistics  costs. 

7. 1.  2  OTHER  CONCERNS  REGARDING  STANDARDIZATION  LEVEL 

Accountability  is  a  critical  factor.  That  is,  if  the  computer  does  not 
work  properly  for  some  reason,  who  is  at  fault  and  who  is  responsible 
for  correcting  the  problem  ?  Under  the  box  F3  approach,  the  answer  is 
comparatively  simple,  as  only  one  supplier  designed  and  built  the  box  in 
question.  For  module  F3  and  build  to  print,  is  it  the  specifier  of  the 
design  or  the  manufacturer  of  the  design?  The  problem  lies  in  the  dif¬ 
ficulty  of  completely  specifying  design,  processes,  etc. 

At  the  module  F3  level,  the  complete  and  unambiguous  specification 
of  complex  logic  functions  can  be  quite  difficult  to  meet.  Typical  mod¬ 
ules  can  have  hundreds  of  signals  and  test  points  that  must  be  specified 
in  terms  of  function  and  timing.  The  specification  problem  can  be  miti¬ 
gated  through  the  use  of  simple  standard  modules,  but  this  may  compro¬ 
mise  design  efficiency  and  performance. 

Problems  also  arise  at  the  build-to-print  level.  Prints  often  may 
not  be  complete  enough  to  build  a  product  that  functions  properly.  The 
first  manufacturer  can  point  to  their  product,  which  works  properly;  the 
second  manufacturer  can  point  to  their  build-to-print  product,  which 
does  not  work  properly.  Resolution  of  these  dilemmas  can  be  difficult. 

Another  critical  concern  is  the  attractiveness  to  producers  of  par¬ 
ticipating  at  different  levels.  A  significant  proportion  of  DoD  computers 
have  been  produced  by  companies  that  have  assumed  responsibility  at  all 
levels:  initial  specification,  design,  build,  test,  and  product  support. 

This  is  box  level  F3.  It  could  be  expected  that  build-to-print  business, 
which  does  not  utilize  the  existing  engineering  expertise,  would  be  un¬ 
attractive  to  a  "full-service"  computer  supplier  and  reduce  "full  support" 
to  the  Navy. 

7.1.3  STANDARDIZATION  LEVEL  SUMMARY 

There  is  no  clear-cut  best  level  at  which  to  standardize.  Nevertheless, 
a  selection  must  be  made.  IBM  recommends  that  the  Navy  standardize 
and  procure  at  the  box  F3  level  because  this  will  best  encourage  com¬ 
petition  and  will  permit  suppliers  the  maximum  flexibility  to  meet  the 
Navy’s  needs.  The  difficulty  of  specification  can  make  module  F3  a 
highly  risky  approach.  As  computers  become  more  reliable  due  to  tech¬ 
nology  improvements,  product  costs  will  become  more  significant  relative 
to  logistics  costs,  and  will  reduce  the  logistics  benefits  of  build  to  print. 


7-3 


7.  2  ARCHITECTURE  CERTIFICATION  PROCESS 


How  does  one  test  different  computers  from  multiple  vendors  to  verify 
that  they  conform  to  the  standard  ISA  ?  The  cost  benefits  available  from 
architectural  compatibility  (i.e.,  common  support  software,  transport¬ 
ability  of  application  code,  and  programmer  training)  can  only  be  captured 
if  the  machines  precisely  represent  the  architecture. 

It  is  difficult  to  guarantee  architectural  compatibility.  Architectural 
discrepancies  can  be  very  subtle  in  nature  and  result  from  such  things  as 
interactions  between  instructions,  data  sensitivities,  and  storage  location 
sensitivities.  It  is  not  feasible  to  exhaustively  test  a  machine  to  be  sure 
that  no  architectural  discrepancies  remain.  For  example,  just  to  check 
all  possible  pairs  of  instructions  for  each  memory  location  with  each  data 
pattern  would  require  more  than  10  years  for  a  typical  machine.  As  a 
result,  one  must  settle  for  reasonable  testing. 

IBM  has  recently  completed  an  Air  Force  study  contract  on  certifica¬ 
tion.  The  Air  Force  faces  the  same  problem  with  multiple  industry 
implementations  of  the  MIL-STD-1750  architecture. 

The  1750  certification  study  began  with  the  identification  of  different 
techniques  for  performing  architecture  verification.  Eight  different  tech¬ 
niques  were  identified.  These  were  investigated  by  site  visits  to  the 
locations  where  they  were  in  use.  These  methods  were  evaluated  on  the 
basis  of  cost  of  implementation  and  its  effectiveness  at  finding  architec¬ 
tural  discrepancies.  The  significant  software  effect  associated  with  not 
finding  architectural  discrepancies  at  the  time  of  certification  lead  to  a 
recommendation  of  a  two-phase  test. 

The  first  phase  of  testing  relies  on  a  "functional"  type  of  test,  which 
is  comprised  of  a  series  of  manually  generated  test  cases.  This  method 
is  summarized  in  Tables  7-1  and  7-2.  The  functional  approach  provides 
a  predefined  minimum  level  of  testing.  The  second  phase  of  testing  is 
based  on  the  "Random"  approach.  This  test  uses  a  random  number  gen¬ 
erator  to  create  instructions  and  data.  These  are  executed  in  a  sequence 
on  both  the  machine  under  test  and  a  simulator.  The  results  are  then 
compared.  Table  7-3  and  Figure  7-1  summarize  this  method. 

The  combined  approach  provided  both  a  predefined  minimum  level  of 
testing  (from  the  functional  test)  and  a  high  degree  of  quality  (from  the 
random  test).  The  latter  is  due  to  the  execution  of  both  instruction  se¬ 
quences  (to  catch  interactive  effects)  and  a  large  number  of  instructions 
and  data  patterns. 

The  Navy  should  consider  such  a  certification  approach  as  part  of  the 
accreditation  process. 


7.3  COMMERCIAL  DEVELOPMENTS 

IBM  examined  the  possibility  of  capturing  the  developments  being  made 
in  the  commercial  computer  environment  and  using  them  as  building 
blocks  for  military  computers.  The  motivation  is  quite  clear  if  one 
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Table  7-1.  Functional  Type  Test  Overview 


•  Test  approach 

—  Apply  a  priori  knowledge  of  computer  testing  to  select  test  cases 
—  Test  boundary  conditions 
—  5,  000  cases  have  historically  been  utilized 

•  Test  case 

—  Initialize  registers  and  main  storage 
—  Execute  one  instruction 
—  Compare  to  predetermined  results 

•  Functional  types  differ  significantly  in  their  intended  applications 
from  engineering  bring  up  through  field  testing 

—  Some  assume  nothing  works,  and  only  a  core  set  of  instructions 
is  available 

—  Others  assume  everything  works  and  all  instructions  are 
available 

•  Quality  depends  upon  number  and  the  amount  of  insight  that  was 
applied  to  selection  of  test  cases 

•  Maturity  can  improve  over  time  by  addition  of  new,  independent  test 
cases 

•  Major  cost  expenditure  element  is  the  generation  of' test  cases 

•  Cost  is  a  direct  function  of  the  number  of  test  cases 


considers  the  relative  magnitudes  of  research  and  development  funds 
available  to  commercial  and  the  resulting  technology  breakthroughs 
that  are  being  made  versus  that  of  the  military  computer  communities. 

IBM  examined  the  price/performance  index  of  its  commercial  com¬ 
puters.  This  index  has  price/performance  improvement  of  approximately 
15%  per  year,  similar  to  the  cost  performance  index  for  military  com¬ 
puters.  This  would  suggest  that  technology  improvements  have  had  sim¬ 
ilar  effect  on  the  two  segments  of  the  same  company  in  spite  of  the  differ¬ 
ences  in  competitive  environments  and  design  objectives.  It  would  appear 
that  the  infusion  of  technology  is  predictable. 

A  closer  examination  of  technology  infusion  into  military  computers 
generally  shows  it  to  be  limited  to  regular  functions  such  as  memory 
arrays,  programmable  logic  arrays  (PLAs),  some  microprocessor 
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Table  7-2.  Functional  iype  Test 


The  following  tests  are  performed: 

•  Test  basic  instruction 

—  All  formats 
—  Function 
—  Addressing 

—  Correct  status  word  alteration 
—  Interrupts 

•  Tests  memory 

—  All  64K  patterns  in  all  locations 
—  Protection 
—  Priority 

•  Test  registers 

—  General  registers  all  64K  patterns 

—  Interrupt  mask  register,  status  register,  fault  register,  CPU 
registers 

•  Miscellaneous  tests 

—  Timers 
—  Discretes 
—  Interrupts 
-  DMA 

—  Random  instruction  for  illegal  OP  code 


devices,  etc.  In  fact,  the  average  integration  level  of  a  modem  military 
medium-class  computer  is  about  1/10  of  that  of  high  function  devices. 

The  following  are  some  considerations  as  to  why  this  is  occurring. 

7.3.1  BUSINESS  VOLUME 

Currently,  technology  is  being  influenced  by  large-volume  demands  for 
two  reasons.  First,  while  device  recurring  costs  are  low,  the  technology 
development  cost  and  the  device  personalization  cost  for  custom  function 
devices  are  very  high.  The  use  of  LSI  technology  is  economical  only  when 
these  fixed  costs  can  be  borne  by  a  large  production  base.  This  kind  of 
production  base  is  not  generally  found  in  the  military  market.  Secondly, 
the  rise  in  demand  for  commercial  consumer  products  has  strained  the 
capacity  of  the  device  manufacturers,  and  they  have  turned  their  attention 
away  from  the  less  profitable  markets. 
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Table  7-3.  Random- Type  Test  Overview 


•  Test  approach 

—  Instructions  and  data  automatically  generated  by  random  number 
generator 

—  Boundary  conditions  not  specifically  tested 
—  Errors  due  to  interaction  of  instructions  are  captured 

•  Test  block 

—  Initialize  registers  and  main  storage 

—  Execute  sequence  of  randomly  generated  instructions  (32- 
instruction  block) 

—  Compare  to  simulated  results 

•  Quality  can  easily  be  increased  by  running  longer 

•  Major  cost  expenditure  element  is  for  the  "golden"  simulator 

•  Cost  is  relatively  independent  of  the  number  of  test  cases.  This  has 
potential  for  lowest  cost  per  test  case  (because  more  cases  are  easily 
obtained  by  running  longer). 


Description 

o  Computer  under  test  is  initialized  to  a  known  state 
o  Variable  length  block  of  random  instructions  generated 
o  Random  block  simulated  under  control  of  implementation  table 
o  Random  block  run  on  hardware 
o  Results  compared  to  simulated  results 
o  If  comparison  fails,  replace  last  instruction  with  no-op  until 
failing  location  found 

O  Replace  last  instruction,  run  and  print  failure  mechansim 
o  When  block  analysis  complete  generate  next  test 

Figure  7-1.  Random- Type  Test 


7-7 


7.3.2  FUNCTIONAL  EQUIVALENCE 


Military  embedded  computers  have  evolved  with  their  own  unique  archi¬ 
tectures,  support  software  systems,  and  interfaces.  As  a  result,  the 
organizations  and  detailed  logic  designs  of  military  computers  are  differ¬ 
ent  from  commercial.  This  limits  the  application  of  LSI  devices  developed 
for  the  commercial  market. 

7.3.3  PERFORMANCE  CONSIDERATIONS 

Transfusion  of  common  function  devices  such  as  data  flow,  PLAs,  etc. , 
is  also  limited  because  most  military  computer  designs  are  performance 
driven.  Experience  has  shown  that,  in  many  instances,  available  high- 
function  devices  can  only  be  used  with  some  sacrifice  in  performance. 
Rather  than  compromise  performance,  the  designer  is  forced  to  use  more 
conventional  logic.  This  is  especially  true  in  the  medium-  and  large- 
class  machines. 

7.3.4  USE  OF  MICROPROCESSORS 

Microprocessors  are  most  likely  to  be  found  as  controllers,  embedded  in 
I/O  modules,  or  CPUs  for  small  class  computers.  Again,  the  need  for 
performance  and  special  military  specified  functions  has  limited  the  ap¬ 
plication  of  microprocessors  in  medium-  and  large-class  computers. 

7.3.5  ENVIRONMENTAL  FACTORS 

The  unique  environmental  requirements  imposed  on  the  military  have  also 
had  an  effect  on  the  use  of  commercially  developed  devices.  First,  there 
are  fundamental  technology  constraints  at  the  device  level,  such  as  sur¬ 
vivability  in  nuclear  environments,  which  constrain  the  choice  of  technol¬ 
ogies.  In  addition,  environmental  considerations  require  that  special 
design  constraints  be  placed  on  the  device  developers,  especially  in  the 
area  of  packaging. 

7.  3.  6  COMMERCIAL  DEVELOPMENTS  SUMMARY 

In  summary,  military  computer  development  trends  are  comparable  with 
the  commercial  computer  developments.  There,  the  similarity  ends. 
Variables  such  as  MIL-SPEC  environment,  control  of  market  offerings, 
business  volume,  DoD  unique  performance  requirements,  and  world-wide 
military  deployment  logistics  make  the  application  of  technology  to  com¬ 
puter  development  drastically  different  for  both  establishments.  This  is 
not  likely  to  change.  However,  at  each  redevelopment  cycle,  commercial 
technology  advances  should  be  assessed  and  integrated  where  possible. 

Box  F^  helps  support  this  goal. 
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•  Sensitivity  Analysis 

—  Even  if  the  full  technology  projections  are  not  realized,  the  con¬ 
clusions  for  redevelopment  are  still  supported.  Of  course,  total 
LCC  savings  are  reduced,  and  the  redevelopment  interval  moves 
out  to  the  right. 

—  For  all  the  acquisition  scenarios  evaluated,  multiple  developers/ 
single  producer  has  a  slight  LCC  advantage  over  other  alternatives, 
but  the  final  selection  must  consider  qualitative  factors  such  as 
operational  readiness,  single-source  susceptibility,  increased  pro¬ 
gram  management,  etc. 

—  Even  with  redevelopment,  the  production  learning  curve  has  an 
effect  on  hardware  acquisition  and  spares  cost,  and  any  significant 
changes  (e.  g. ,  dividing  computer  requirements  between  two  pro¬ 
ducers,  or  not  realizing  total  production,  etc.)  in  the  "defined 
market"  will  cause  an  increase  in  LCC. 

—  Hardware  competitive  savings  of  anywhere  from  10%  to  20%  sup¬ 
port  the  need  for  multiple  developers  and  can  produce  from  5%  to 
10%  total  Life  Cycle  Cost  savings. 

•  Maintenance  Considerations 

—  The  objective  of  mission  maintenance-free  computers  is  not 
realizable  in  the  near  term  (next  10  years) ;  aspects  of  redundancy, 
partitioning,  and  distributed  systems  with  fault  tolerance  must  be 
considered. 

—  The  maintenance/lLS  concept  of  SRA  discard  is  optimal  for  the 
large  and  medium  computers;  however,  the  cost  penalties  of  WRA 
to  depot  may,  in  the  future,  be  acceptable  in  light  of  other  considera¬ 
tions;  e.  g. ,  maintenance  personnel. 

—  The  maintenance  personnel  problem  (especially  in  the  Data  Spec¬ 
ialist  area)  may  be  mitigated  by  the  following  considerations: 

—  Mission  maintenance-free  computers 
—  RIW/WRA  to  depot  support  concepts 
—  Commonality  between  classes  of  processors  to  reduce 
multiple  training  aspects 

—  Extensive  self-diagnostics/BITE  in  computers,  thereby 
reducing  required  skill  levels. 


8.  3  PROFITABILITY  ANALYSIS 


The  profitability  analysis  evaluated  (from  a  seller’s  perspective)  whether 
a  reasonable  and  attractive  business  opportunity  existed,  based  on  market 
projection  data  provided  by  the  Navy.  It  also  attempted  to  answer  two 
other  questions:  (1)  Should  the  Government  fund  development?,  and  (2) 

Is  "redevelopment"  still  profitable?  The  following  conclusions  resulted: 

•  With  redevelopment  (5-year  production  market  assumed),  a  reasonable 
business  opportunity  existed  for  all  three  classes  of  computers;  however, 
sufficient  ROI  seldom  exists  to  make  unfunded  developments  attractive. 


8-3 


•  Risk  to  Government  market  stability  further  reduces  the  incentive  to 
invest.  This,  coupled  with  ROI  considerations,  means  that  the  Navy 
must  provide  development  funds. 

•  Savings  in  production  from  competitive  development  can  offset  the 
Navy's  cost  for  multiple  developments. 

•  On  a  profitability  basis,  multiple  producers  further  reduce  revenue 
and  ROI  by  reducing  the  production  quantity  for  each  producer.  Hence, 
multiple  developers/single  producer  seem  optimal. 


8.4  ACQUISITION  CONSIDERATIONS 


The  primary  objective  of  the  Acquisition  Framework  Analysis  Task  was 
to 

•  Review  current  Navy  computer  acquisition  policies 

•  Integrate  the  technology,  LCC,  and  profitability  and  accreditation 
considerations 

•  Formulate  a  potential  procurement  framework. 

This  task  was  constructed  from  a  procurement/contracts  reference. 

The  results  of  the  Acquisition  Framework  Tasks  are  as  follows: 

•  Establish  a  shipboard  computer  Central  Acquisition  Agency  responsible 
for  planning,  requirements  definition,  coordinating  user  commitments, 
specification  development,  funding,  procurement,  and  overall  program 
management.  Fund  this  agency  on  an  independent  basis  to  avoid  con¬ 
flicts. 

•  Production  contract  commitments  should  be  considered  on  a  multilayer 
funding  basis  or  on  a  requirements  basis;  the  former  is  more  desirable. 

•  Manage  with  the  goal  of  periodically  redeveloping  approximately  every 
5  years. 

•  To  effectively  manage  redevevelopment  to  ensure  timeliness  and 
responsiveness  to  evolving  Navy  priorities,  establish  on-going  studies 
within  the  Navy  to  measure  and  analyze  trends,  priorities,  etc. ,  for 
accreditation. 

•  The  recommended  acquisition  scenario  consists  of 

—  Dual  development  awards 
—  Single  production  source 
—  Multilayer  funded  production  procurement 
—  Redevelopment  after  approximately  5  years. 


8.5  CONCLUSION 


From  the  described  study  results,  IBM  concludes  that  the  defined  concept 
of  accreditation  is  worth  evaluating,  appears  to  have  a  reasonable  evolu¬ 
tionary  basis  for  implementation,  provides  a  meaningful  benefit  to  the 
Navy,  and  should  be  implemented.  Further  studies  are  warranted  to 
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Section  8 

SUMMARY  AND  CONCLUSIONS 


The  accreditation  framework  proposed  by  IBM  as  a  result  of  this  study 
contract  has  as  its  basis  five  key  premises: 

•  Periodic  redevelopment  should  be  implemented. 

•  Multiple  competitive  developments  and  a  single  production  source 
is  preferable. 

•  A  reasonable  business  case  must  be  constructed  for  industry,  based 
on 

—  Adequate  market  projections 
—  Government  funding  for  development. 

•  An  acquisition  policy,  based  on  a  commodity  procurement  agency, 

Box  F3,  ISA  certification  for  software  portability,  and  production  com¬ 
mitments  is  desirable. 

•  On-going  concept  formulation  studies  should  be  performed  to  ade¬ 
quately  provide  a  foundation  for  decisions  regarding  accreditation. 

The  proposed  accreditation  framework  is  an  evolutionary  rather 
than  a  revolutionary  one  and  is  based  on  the  assumption  that  drastic 
change  could  be  chaotic  and  detrimental.  The  Navy's  computer  acquisi¬ 
tion  policies  are  continually  changing  (e.  g. ,  NECS/UYK-43)  and 
Accreditation  was  defined  by  IBM  as  the  next  step  beyond  current  policy 
to  meet  future  needs  and  is  consistent  with  evolving  computer  develop¬ 
ment  trends. 

As  was  described  in  the  Study  Methodology  subsection,  IBM  chose 
to  focus  on  four  analysis  areas: 

•  Technology  trends  and  projections 

•  Life  Cycle  Cost  (benefits  to  the  buyer  (Navy)) 

•  Profitability  (benefits  to  seller  (Industry)) 

•  Acquisition  considerations. 

The  following  is  a  summary  of  results  of  the  Accreditation  study  and  is 
organized  by  the  four  selected  areas  of  study. 


8.1  TECHNOLOGY  TRENDS  AND  PROJECTIONS 

IBM  examined  device  as  well  as  military  computer  trends,  based  on 
IBM  FSD  experiences  of  computer  development  and  production.  IBM 
found  that 

•  Device  level  integration  and  performance  increases  (40%/year) 
exceeded  that  of  computers  at  the  box  level  («* *  16%/year) . 

•  Computer  reliability  is  improving  at  approximately  14%  year  (again 
at  the  box  level) ,  but  may  be  somewhat  offset  by  more  complex,  higher 
function  computers  in  the  future. 

•  Computer  price/performance  is  decreasing  at  approximately  16%/year. 
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In  summary,  based  on  past  history,  technology  advances  for  the  near 
future  (next  10  years)  are  likely  to  continue,  and  its  benefits  suggest 
a  policy  of  periodic  technology  infusion. 


8.  2  LIFE  CYCLE  COST 


The  Life  Cycle  Cost  analysis  focused  on  four  areas  of  interest  for 
accreditation: 

•  Effect  of  technology  on  LCC 

•  Optimizing  development  vs  acquisition/logistics  support  costs 

•  Sensitivity  analysis  for 

—  Acquisition  scenarios 
—  Rate  of  technology  improvement 
—  Production  learning  curve  considerations 
—  Competitive  savings  during  the  production  acquisition 

•  Maintenance  considerations 

—  Logistics  concepts  (depot,  SRA,  vs.  WRA  repair) 

—  Mission  maintenance-free  computers 
—  Maintenance  personnel  Impacts. 

In  examining  all  potential  aspects  of  Accreditation  which  could  provide 
cost  improvement,  IBM  found  that,  in  an  estimated  total  computer  pro¬ 
gram  cost  for  the  Navy  of  $2  billion,  reductions  of  $0.  5  to  $0. 6  billion 
could  be  achieved  by  periodic  redevelopment. 

The  following  is  a  summary  of  the  Life  Cycle  Cost  Analysis  study 
task  results: 

•  Technology  Effect  on  LCC 

—  Hardware  cost/performance  decreases  substantially,  reducing 
LCC  in  the  areas  of  initial  installed  hardware  and  spares. 

—  Improving  computer  reliability  will  reduce  LCC  in  the  areas  of 
spares  and  recurring  O&M. 

—  For  the  assumptions  baselined  (fixed  computer  function,  constant 
year  dollars,  and  an  established  design  in  1989),  and  for  the 
technology  projections  estimated,  LCC  for  1989  computers 
will  be  nominally  one-fifth  of  what  it  is  today. 

•  Optimal  Redevelopment 

—  Based  on  the  estimated  technology  projections  and  computer 
development  and  support  costs,  a  periodic  development  approxi¬ 
mately  evexy  5  years  appears  reasonable. 

—  Timely  redevelopment  provides  the  lowest  total  LCC;  e.  g. ,  any¬ 
where  from  17%  to  25%  over  no  redevelopment. 

—  Waiting  too  long,  (  >5  years)  clearly  costs  more. 
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revalidate  conclusions,  properly  integrate  priorities,  and  define  a  de¬ 
tailed  plan  to  make  accreditation  happen. 

Accreditation  as  structured  by  this  study  appears  reasonable.  It 
has  attractive  features  for  industry  and  is  responsive  to  the  Navy's 
needs.  IBM  supports  this  progressive  concept. 
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Section  9 

RECOMMENDED  FUTURE  EFFORTS 


Although  this  study  has  established  a  potential  framework  for  Accredi¬ 
tation  that  appears  to  be  a  reasonable,  evolutionary  step  in  future  Navy 
computer  acquisition  policy,  further  analysis  and  definition  by  the  Navy 
of  this  concept  is  warranted  prior  to  any  policy  implementation. 

During  the  Navy  review  of  IBM’s  Accreditation  study  results,  some 
areas  of  further  study  were  suggested,  alternative  acquisition  policies 
considered,  and  revalidation  of  baseline  data  and  assumptions  discussed. 
The  following  summarizes  additional  study  efforts  which  should  be  con¬ 
sidered  in  future  studies. 

•  Continuing  Revalidation  of  baseline  assumptions  and  data  used  in  the 
three  major  analysis  areas  (LCC,  profitability,  acquisition  policies) 

•  Further  explore  the  aspects  of  computer  maintenance  personnel 
minimization,  particularly  in  the  areas  of 

—  More  reliable,  (mission  maintenance  free?)  computers  -  system 
partitioning  considerations,  etc. 

—  Trade  off  maintenance  manpower  problems  (limited  resources, 
training,  system  operation)  against  current  ship  logistics  priorities 

•  Analyze  an  Accreditation  concept  where  commonality  exists  between 
all  three  computer  types  (small,  medium,  and  large) :  feasibility,  LCC 
effect,  acquisition  policy,  etc. 

•  Evaluate  the  effects  of  computer  retrofit,  based  on  periodic 
redevelopments 

•  Develop  a  strawman  detailed  implementation  plan  to  define,  step-by- 
step,  a  checklist  of  actions  required  to  initiate  policy  for  accreditation. 

•  Examine  the  policy  of  HOL  standardization,  which  could  potentially 
have  an  influence  on  computer  hardware  standardization  and  even  on  the 
concept  of  accreditation 

•  Re-evaluate  the  potential  roles  of  the  Accreditation  principals  (plat¬ 
form  manager,  development  manager,  etc. )  to  ensure  consistency  with 
Navy  organizational  policies. 

IBM  would  welcome  discussions  on  any  of  the  preceding  if  further  follow- 
on  activity  for  Accreditation  is  contemplated. 
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Appendix  A 

ASSUMPTIONS  FOR  MODEL  IN  LCC  ANALYSES 


The  Constituent  elements  and  basic  assumptions  used  in  the  Life  Cycle 
Cost  Analysis  are  defined  and  explained  in  this  appendix. 

A  hardware  baseline  was  required  to  provide  some  reasonable 
scenarios  with  which  to  extrapolate  to  future  computer  accreditation 
concepts.  The  Navy  has  two  computers  which  are  standards  today  -  the 
AN/UYK-7  and  the  AN/UYK-20.  Indications  are  that  future  weapons 
systems  will  require  these  two  classes  of  computers  as  well  as  a  small 
"under-the-covers"  processor.  Therefore,  for  this  study  three  classes 
of  future  computers  were  considered,  defined  as  small,  medium,  and 
large.  The  data  required  for  each  class  of  machine  includes  estimates  of 
acquisition  cost,  quantities,  reliability,  development  cost,  and  production 
nonrecurring  start-up  (NRSU). 


A.  1  CONSTITUENT  ELEMENTS 


The  Life  Cycle  Cost  model  is  composed  of  three  constituent  elements: 
development,  investment,  and  support  costs. 

A.  1.1  DEVELOPMENT  COST 

The  development  costs  consist  of  contractor  and  Government  cost.  For 
this  study,  the  development  costs  were  estimated  by  a  cost  engineering 
group  for  each  class  of  computers.  The  development  was  assumed  to  be 
a  full-scale  development  engineering  program  for  a  form-fit-function 
computer  which  would  then  be  followed  by  a  full  production  phase. 

It  was  realized  that  this  would  represent  the  lowest  cost  procurement 
approach  as  compared  to  build  to  print,  module  F^,  or  variations  of  each. 
The  development  cost  figure  was  maintained  at  a  fixed  sum  independent 
of  year  of  development.  This  figure  was  also  used  as  a  base  for 
establishing  Government  development  support  costs,  which  were  fixed 
at  one-half  of  Contractor  development  costs.  Table  A-l  summarizes 
items  related  to  development  costs. 

A.  1.2  INVESTMENT  COSTS 

The  investment  cost  is  made  up  of  four  major  elements:  (1)  acquisition 
of  prime  equipment  hardware  (2)  nonrecurring  start-up  (NRSU)  costs , 

(3)  Government  program  management,  and  (4)  acquisition  of  support 
equipment,  training,  supply  support,  and  technical  data.  The  unit  hard¬ 
ware  cost  was  established  for  each  class  of  machine.  The  cost  was 
modified  during  redevelopment  cycles  to  reflect  the  technology  and  cost 
improvements  projected  during  that  time  period. 
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Table  A-l.  Items  Related  to  Development  and  Production  NRSU  for 
Navy  Computer  Accreditation  Study 


Development 


Rate 

Related 


Electrical  Design 
Mechanical  Design 
Environmental  Engineering 
Systems  Engineering 
Qualifications  Testing 
Reliability  Demonstration 
Manufacturing  Support 
R/M,  QE,  CA,  ME,  PT 
Test  and  Support  Software 
ILS 
IE 

Data  Requirements 
Engineering  Test  Hardware 
Test/BI  Equipment 


Production  NRSU 


Rate 

Related 


Software  Cleanup 

Other  Design  Changes 

Manufacturing  Test/Env.  Equipment 

R 

Tooling 

R 

Rearrangement  Costs 

R 

R/M 

Engineering  Support 

Data  Requirements 

Prime  hardware  acquisition  costs  are  the  total  costs  to  procure  the 
quantity  of  computers  required  to  equip  all  designated  ships.  It  is  the 
product  of  quantity  required  and  the  unit  cost.  It  is  expected  that  reason¬ 
able  quantities  for  each  class  of  machine  could  be  based  on  the  history  of 
the  AN/UYK-7  and  AN/UYK-20.  The  Navy  Embedded  Computer  Review 
Panel  had  gathered  such  data  for  their  final  report.  An  excerpt  is 
presented  here: 


".  .  .  the  sponsors’  data  would  yield  a  total  through  1985 
of  $379M  for  UYK-7's  @$250k  each,  and  $126M  for  UYK-20’s 
@$50k  each.  The  commodity  managers’  forecasts  similarly 
would  yield  $505M  for  UYK-7’s,  and  $380M  for  UYK-20’s  .  .  . 
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These  volumes  were  predicated  on  a  10-  to  15-year  span  of  time. 
Because  future  computers  are  in  increasing  demand,  it  was  decided  that 
the  estimates  would  more  realistically  be  applicable  to  a  10-year  period, 
and,  therefore,  the  data  was  used  as  such.  The  small  class  of  computers 
was  generated  from  IBM  FSD's  Marketing  Forecast  group  and  was  deter¬ 
mined  to  be  approximately  10,000  cards  in  a  10-year  period.  The 
quantities  for  the  large  and  medium  components  were  derived  by  dividing 
the  business  volume  by  the  individual  cost.  (e.  g. ,  $505M/$205k  = 

2020  computers.)  Because  the  technology  trend  charts  pointed  out 
relatively  constant  cost  for  increasing  performance,  the  costs  of  the 
large  and  medium  machines  were  assumed  to  be  equal  to  that  of  the 
predecessor  UYK-7  and  UYK-20,  that  being  $250k  and  $50k  respectively. 


The  small  processor  cost  was  estimated  by  IBM  FSD  as  approximately 
$5k  (see  Table  A-2). 

Table  A-2.  Acquisition  Cost/Quantity  Summary 

Parameter 

Class 

Small 

Medium 

Large 

Acquisition  Cost  ($K) 

5 

50 

250 

Reliability  (MTBF)  (h) 

50,000 

2,000 

1,400 

Total  ($M) 

50 

380 

505 

Projected  Quantities 

(10,000) 

(7,  600) 

(2,020) 

NRSU  costs  were  established  for  each  class  of  computer  and  re¬ 
mained  constant  irrespective  of  year  of  procurement.  Adjustments  were 
made  for  a  reduced  production  rate  when  the  concept  of  multiple  pro¬ 
ducers  was  considered. 

The  NRSU  items  which  were  considered  for  each  class  of  computer 
are  summarized  in  Table  A-l.  Those  particular  items  most  influenced 
by  the  rate  of  production  are  identified  with  an  R.  The  production  rate 
was  assumed  to  be  linear  for  a  10-year  period.  Table  A-3  summarizes 
the  costs.  NRSU  costs  are  illustrated  for  three  production  rates. 

This  study  chose  to  use  the  commodity  manager's  forecasts  vs.  the 
sponsor's  data  forecast  (Table  A- 2).  It  is  expected  that  the  true  usage 
would  likely  fall  between  these  two  and  that,  due  to  future  growths  of 
computers,  a  proper  estimate  would  be  that  of  the  sponsor's  data 
forecast.  It  is  worthy  to  note  that  although  the  costs  as  tabulated  are 
precise,  in  reality,  a  range  exists  and  that  these  values  merely  fall 
within  the  bounds.  For  example,  see  Figure  A-l. 

Government  Program  Management  was  maintained  at  a  60 -person 
level  of  support  effort  for  all  three  classes  of  machines.  This  figure 
as  obtained  from  the  Navy,  based  upon  the  present  personnel  level 


A-3 


Table  A-3.  Full-Scale  Engineering  Development  and  Production 
Nonrecurring  Start-Up  for  Navy  Computer  Accreditation  Study 


Class 

Development 
Contractor/ Government 
($M) 

Production  Rate  ($M) 

(100%) 

(50%) 

(30%) 

Small 

1.5 

0.8 

1.3 

1.2 

1.2 

90/mo 

45/ mo 

30/mo 

Medium 

10.0 

5.0 

15.0 

10.0 

8.5 

60/mo 

30/mo 

20/mo 

Large 

30.0 

15.0 

18.0 

15.0 

13.5 

20/mo 

10/mo 

6/mo 

22 

20 

18 

16 


| 


3 

co 

cc 

z 


14 

12 

10 

8 


6 


4 


2 


0 


20/month 


20/month 


30/month  45/month  90/month 

Sma" 


50 

%  of  Production  Rate 


100 


Figure  A-l.  Production  NEtSU 
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application  to  support  the  AN/UYK-7,  AN/AYK-14,  and  AN/UYK-20. 

IBM  assumed  an  allocation  of  this  personnel  level  as  a  25  man  level  of 
effort  each  for  the  large-  and  Medium  class  computers,  and  at  a  10- 
person  level  of  effort  for  the  small  class  computer. 

The  support  level  established  covered  a  single  developer/single 
producer.  The  base  personnel  level  of  support  was  adjusted  upward  for 
multiple  developments,  suppliers,  or  reacquisitions.  It  was  assumed 
that  each  development,  new  producer,  or  reacquisition  introduced  a  new 
and  different  technology  and  therefore  required  multiple  support 
personnel.  The  adjustment  made  considered  utilizing  existing  personnel 
in  common  support  areas  and  adding  people  to  support  unique  areas. 

Support  equipment  costs  were  considered  for  all  three  classes  of 
computers.  The  current  technology  levels  provide  for  extensive  built-in 
test  and  fault  isolation  capabilities.  This  currently  available  capability 
eliminates  the  need  for  ship-level  support  equipment  to  facilitate  the  iso¬ 
lation  of  computer  failures  to  the  shop-replaceable  unit  (SRU)  level. 

The  sets  of  support  equipment  required  for  the  depot  are  calculated 
based  on  the  projected  usage  of  the  item  and  the  depot  capability.  For  the 
large-  and  medium-class  computers,  the  digital  assemblies  were  assumed 
to  be  discard,  so  only  the  power  supplies  and  memory  assemblies  required 
depot  support  equipment. 

The  initial  training  element  includes  all  costs  for  training  of  the 
initial  cadre  of  professional  and  maintenance  personnel.  For  this  study, 
it  was  assumed  that  the  host  system  training  would  provide  the  necessary 
training  to  maintain  the  computer  on  a  recurring  basis. 

Supply  support  includes  the  cost  of  all  spare  replaceable  units  for 
system  support.  This  includes  the  spares  necessary  for  ship  support, 
depot,  pipeline,  and  condemnation.  The  total  spares  cost  for  each  replace¬ 
able  unit  is  a  function  of  the  quantity  of  spares  required  and  production  unit 
cost.  The  quantity  required  is  determined  by  the  availability  objective, 
which  in  this  case  was  assumed  to  be  0. 99.  Spares  were  considered  as 
being  procured  concurrent  with  production,  and  no  cost  factors  were 
applied  to  the  unit  cost.  The  amount  of  spares  in  the  inventory  increased 
when  different  F^  equipment  was  deployed. 

A.  1. 3  SUPPORT  COSTS 

The  support  cost  encompass  five  major  areas:  (1)  corrective  main¬ 
tenance,  (2)  support  equipment  maintenance,  (3)  supply  support, 

(4)  data  management,  and  (5)  packaging  and  shipping.  To  compute  these 
costs,  a  maintenance  concept  and  operational  criteria  had  to  be  defined  as 
follows . 

The  recurring  costs  were  computed  for  the  discard  and  repair  al¬ 
ternatives  for  the  different  classes  of  machines.  The  costs  for  the  large- 
and  medium-scale  computers  were  based  upon  a  cost-effective  discard 
concept  while  the  small-scale  computer  was  repaired  at  depot. 
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Corrective  maintenance  includes  the  operational  site  or  organiza¬ 
tional  repair  level  and  depot  level  repair  costs.  The  operational  site 
level  cost  element  includes  labor  and  maintenance  costs  associated  with 
verification  and  repair  of  the  unit  at  the  ship  level.  Depot  level  costs 
include  the  repair  labor  and  materials  costs  associated  with  units  re¬ 
paired  at  depot.  These  costs  include  the  test  and  repair  of  the  power 
supplies  and  memory  modules  for  the  medium  and  large  computer 
and  all  costs  incurred  for  the  one  subassembly  unit  of  the  small  computer. 

Support  equipment  maintenance  costs  include  the  cost  to  operate  and 
maintain  the  support  equipment  required  at  the  depot  level.  This  cost 
is  based  on  a  percentage  of  the  initial  acquisition  cost  of  the  support 
equipment. 

The  initial  and  recurring  data  management  element  includes  the 
cost  of  reproduction,  distribution,  and  file  maintenance  of  technical 
data.  It  is  a  function  of  the  number  of  pages  of  technical  data  and  a  cost 
factor  for  reproduction,  distribution,  and  data  management. 

The  packaging  and  shipping  cost  element  applies  to  all  units  shipped 
between  the  ship  and  depot.  It  is  a  function  of  the  expected  number  of 
failures  resulting  in  a  repair  at  depot  and  a  standard  cost  factor  for 
packaging  and  shipping. 


A. 2  RELIABILITY 

The  values  of  reliability  for  the  three  future  classes  of  machines  were 
again  equated  to  the  present  values  for  the  AN/UYK-7  and  AN/UYK-20. 
Based  upon  communications  with  the  Naval  Underwater  Systems  Center, 
the  data  in  Table  A-4  was  derived.  The  MTBF  numbers  used  in  the 
study  for  the  medium-  and  large-class  machines  were  obtained  by  fac¬ 
toring  the  observed  AN/UYK-7  and  AN/UYK-20  MTBF  values  for  false 
removals  and  induced  failures  to  account  for  maintenance  actions  and 
spares  requirements. 


Table  A-4.  Reliability  Values 


Class  of  Machine 

Reliability 

Hours  -  MTBF 

Large 

1,400** 

Medium 

2,000 

♦Small 

50,000 

*  The  small  processor  card  level  class  was  estimated  by  IBM 
because  no  such  class  currently  exists  with  which  to  compare. 


**  Averaged  for  Typical  complexity. 
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A.  3  LOGISTICS  ESTIMATES 


In  addition  to  the  assumptions  associated  with  the  input  parameters,  the 
following  general  assumptions  for  the  logistics  estimates  were  made.  The 
computers  would  operate  on  an  average  of  720  hours  per  month,  and  the 
mission  would  last  90  days.  The  model  provides  for  reliability  growth, 
the  computers  are  maintained  as  a  fixed  function,  and  there  is  box  level 
F3.  Spares  are  procured  coincident  with  production  buys,  and  there  is 
a  fixed  cost  for  recurring  training.  Operational  and  support  software 
costs  are  not  included  in  the  overall  system  LCC.  These  assumptions 
and  the  model  inputs  are  summarized  in  Table  A-5. 

The  results  of  the  model  with  these  assumptions  for  the  three  classes 
of  computers  are  summarized  in  Figures  A-2,  A-3  and  A-4,  where  the 
Total  Program  Cost  is  shown  as  a  function  of  the  year  of  development 
start. 
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Table  A-5.  General  Assumptions  for  LCC  Analysis 


•  Built-in  test/diagnostic  capability  held  constant 

-  Isolation  to  assembly  w/o  support  equipment 

•  15-year  operation  support  period 

•  720  hours/month  operation 

•  Module  spares  on  ship 

-  90 -day  consumption  level 

•  Fixed  function 

•  Fixed  cost  for  recurring  training 

•  Box  level  F3 

•  Spares  procured  coincident  with  production  buy 

•  Software  costs  excluded 

•  Development  cost  Production  Volume 


Qty 

U/C 

Total  Costs 

-  Small 

1.  5  MIL 

10,000 

5K 

50  MILLION 

-  Medium 

10.0  MIL 

7,600 

50K 

380  MILLION 

-  Large 

30.0  MIL 

2,020 

250K 

505  MILLION 

Production  rate  vs  nonrecurring  start-up  (NRSU)  cost  ($M) 

Production  rate:  100% 

No.  of  Producers:  1 

50% 

2 

33%  -  25% 
3-4 

-  Small 

1.3 

1.2 

1.2 

-  Medium 

15.0 

10.0 

8.5 

-  Large 

18.0 

15.0 

13.5 

•  Competitive  effects 

-  Assumption  for  parametric  analysis 

hardware  and  spares  cost  savings  10%,  20% 

Government-Development  Costs:  One-half  of  contractor  development  costs 
Government  program  Management:  $50K  per  manyear 
•  60 -man  level  of  effort  support 

•  25  men  (large  computer) 

•  25  men  (medium  computer) 

•  10  men  (small  computer) 

Government  program  manpower  allocation 


-  Small 

-  Medium 

-  Large 


One  Producer 
During  During 

Production  O&S 


Addl/Producer 
During  During 
Production  O&S 


10  men  4 


2  2 


25 


10  8  4. 5 


25 


10  8  4.5 
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Baseline  Input  Small 
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•  MTBF:  50,000  hr 

•  Cost:  $5,000 

•  Unique  Assemblies:  1 

•  Total  Quantity:  1 

•  Deployment  —  10,000  Computer/667  Ships 


79  84  89 

Year  of  Development  Start 


Figure  A~2.  Total  Program  Cost  Components  -  Small  Machine 
(Without  Redevelopment) 
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Baseline  Input  Medium 

*  MTBF:  2000  hr 

*  Cost:  $50,000 

*  Unique  Assemblies:  17 

*  Total  Quantity:  32 

t  Deployment  —  7600  Computer/363  Ships 
-  Ships:  16  20  30  29  30  19 

—  Quantity/Ship:  12  4 

*  Training:  10  Days  @  $100,000 
■  Manuals:  500  Pages  @  $262,500 

*  Inventory  Items:  200 
Maintenance  Concept:  Discard 


40 

15 


44 

20 


48 

30 


45 

40 


42 

50 


Spares 
Recurring  logistics 


Other  program  costs 


79 


84 

Year  of  Development  Start 


89 


Figure  A-3.  Total  Program  Cost  Components  -  Medium  Machine 
(Without  Redevelopment) 
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Baseline  Input  Large 


•  MTBF:  1400  hr 

•  Cost:  $260,000 


Figure  A-4.  Total  Program  Cost  Components  -  Large  Machine 
(Without  Redevelopment) 
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Appendix  B 

MANPOWER  PLANNING 


As  noted  in  Section  4,  a  shortage  of  skilled  Data  System  Technicians 
presently  exists  in  the  fleet.  This  shortage  is  projected  to  continue 
into  the  next  decade,  unless  action  is  taken  to  relieve  the  problem.  As 
part  of  this  study,  information  was  received  from  Navy  sources,  analyzed 
against  present  hardware  performance  through  the  LCC  model  and 
summarized  to  compare  against  present  planning  figures.  A  dichotomy 
is  found  to  exist  in  that  the  personnel -hour  requirements  projected  from 
the  LCC  model  analysis  differ  significantly  from  the  personnel  level 
assignments  needed  to  satisfy  demands  from  existing  platforms,  using 
the  present  standard  computers. 


B.l  NAVY  PLANNING 

Using  information  provided  by  Navy  sources,  projected  costs  were 
generated  to  cover  hardware  acquisition  costs  at  the  planned  rate, 
consumption  spares  cost  for  a  15-year  support  period,  and  maintenance 
costs  for  the  15-year  support  period.  The  quantities  for  hardware 
acquisition  are  1,  000  AN/UYK-7S  at  a  $275,  000  unit  price  and  3,  000 
AN/UYK-20s  at  a  unit  price  of  $55,  000.  Average  spares  for  the  AN/UYK-7 
cost  approximately  $15,000  per  year  and  for  the  AN/UYK-20  cost 
approximately  $5,  500  per  year.  The  cost  to  the  Navy  for  operational 
and  training  costs  for  the  2000  Data  System  Technicians  averages 
approximately  $22,500  per  computer  per  year.  These  costs  are 
summarized  in  Table  B-l. 


Table  B-l.  Costs  in  Millions  of  Dollars 


Item 

AN/UYK-10 

AN/UYK-7 

TOTAL 

Hardware  Acquisition 

165 

275 

440 

Consumption  Spares  (15  years) 

248 

225 

473 

Maintenance  (15  years) 

720 

480 

1200 

TOTAL 

1133 

980 

2133 

B.2  ANALYSIS 

The  Navy  supplied  MTBF  and  MTTR  figures  for  the  AN/UYK-20  standard 
computer  are  6, 132  hours  MTBF  and  15  minutes  MTTR.  Inserting 
these  cost-driving  parameters  into  the  LCC  model,  we  find  the  number 
of  personnel-hours  required  to  support  the  hardware  failures  expected 
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during  the  operational  period  of  15  years  may  be  calculated  and  translated 
in  dollar  costs.  Significant  differences  exist  in  the  costs  projected  from 
the  present  planning  and  those  yielded  from  the  LCC  analysis.  The  results 
are  shown  in  Table  B-2. 

Table  B-2.  Percentage  Allocation  of  Costs  for  AN/UYK-20 


Item 

Navy  Planning 

LCC  Analysis 

Hardware  Acquisition 

15% 

56% 

Consumption  Spares 

22% 

43% 

Maintenance 

63% 

1% 

The  significant  differences  between  the  percentages  of  costs  from 
two  sources  needs  reconciling.  Several  possible  areas  for  future 
investigation  are  suggested  and  listed: 

•  The  Data  System  Technician  is  utilized  not  only  to  maintain  computer 
hardware,  but  also  to  resolve  any  system  discrepancies  associated  with 
computer  or  host  system  software. 

•  The  requirement  for  one  or  more  Data  Systems  Technicians  to  be 
included  in  the  ship's  company  is  driven  by  the  host  system  and  other 
peripheral  equipment  rather  than  computer  maintenance  only. 

•  The  Navy  planning  figures  may  be  influenced  by  significantly  older 
vintage  technology  still  in  use  in  the  fleet  and  have  not  been  adjusted  to 
take  advantage  of  the  improved  performance  of  the  later  technology 
hardware. 

It  is  thus  recommended  that  a  further  study  be  conducted  to  resolve 
the  issue  of  personnel  hours  vs  personnel  loading  as  the  significant  main¬ 
tenance  cost  driver.  This  study  should  not  be  limited  to  the  computer 
only  but  should  include  the  number  of  deployed  systems  supported  by  the 
standard  or  embedded  computer.  The  study  should  also  consider  other 
responsibilities  that  utilize  the  Data  Systems  Technician's  time. 
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Appendix  C 
ARINC 


Aeronautical  Radio  Incorporated  (ARINC)  is  an  airline-owned  entity  which 
has  as  one  of  its  purposes  the  development  of  specifications  for  use  in 
procuring  avionic  equipment.  The  procedures  for  developing  the  speci¬ 
fications  and  the  procurement  practices  are  of  interest  because  it  is 
generally  accepted  that  ARINC  is  effective  and  because  many  of  the  prob¬ 
lems  faced  by  the  airlines  are  shared  by  DoD.  Through  ARINC,  the  air¬ 
lines  have  been  able  to  buy  avionic  equipment  of  relatively  high  reliability 
and  low  cost.  Development  times  are  reasonable,  and  competition  is 
maintained.  Some  of  the  relevant  aspects  of  ARINC  are  discussed  in  this 
section. 

Avionic  requirements  are  defined  through  an  open  forum  consisting  of 
participants  from  potential  vendors,  the  airline  industry,  and  technical 
representatives.  This  open  forum  is  known  as  Commercial  Acquisition 
Methodology  (CAM).  The  airlines  make  the  requirement  for  new  avionic 
equipment  known  for  a  5-year  period  through  the  CAM.  If  there  is  suffi¬ 
cient  interest  expressed  by  the  manufacturers  in  providing  a  given  piece 
of  equipment,  ARINC  generates  a  "characteristic",  or  specification,  for 
the  equipment.  This  precondition  assures  the  existence  of  available  com¬ 
petition. 

The  ARINC  characteristic  is  a  high-level  specification  for  the  equip¬ 
ment.  The  equipment  is  specified  at  the  form-fit-function  ((F^)  level. 

Such  things  as  form  factor,  weight,  interconnections,  and  reliability,  as 
well  as  functional  performance,  are  specified.  However,  there  are  very 
few  second-tier  specifications  imposed  on  the  developer. 

In  most  instances,  manufacturers  develop  equipment  independently 
and  submit  the  equipment  to  the  airlines  for  evaluation.  All  environ¬ 
mental  testing  and  arrangements  for  FAA  certifications  are  performed  by 
the  vendors  prior  to  delivery  to  the  airline.  No  procurement  decision  is 
made  until  the  airlines  have  completed  their  evaluation. 

A  reliability  improvement  warranty  is  incorporated  in  the  procure¬ 
ment  contact.  The  manufacturer  commits  to  maintain  the  equipment  for 
a  period  of  time  at  an  agreed  upon  dollar  value.  This  amount  acts 
as  an  incentive  to  incorporate  reliability  improvements  in  the  equipment. 
Fewer  repairs  means  that  the  vendor  effectively  receives  greater  profit 
because  the  maintenance  funds  are  not  used  up;  conversely,  excessive 
repairs  reduce  profits. 

The  successful  vendor  is  given  a  favored  vendor  status,  which  is 
enjoyed  as  long  as  the  equipment  performance  remains  satisfactory. 

This  is  determined  through  a  continuous  monitoring  process. 

While  there  are  some  obvious  differences  between  the  needs  of  the 
airlines  and  the  needs  of  the  Shipboard  Navy,  there  appears  to  be  some 
elements  of  the  ARINC  procurement  process  that  are  worth  considering: 
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•  The  use  of  a  high-level  specification,  unencumbered  by  lower-tiered 
specifications,  permits  maximum  supplier  flexibility  to  meet  the  require¬ 
ments  of  the  job. 

•  RIW  provides  the  incentive  for  the  manufacturers  to  develop  more 
reliable  products  and  incorporate  technology  upgrades  that  improve 
reliability. 

•  The  CAM  provides  long-term  requirements  information  to  the  vendors, 
which  reduces  vendor  investment  risks. 
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